This document discusses the importance of code reviews for programmers. It notes that code reviews can increase quality, reduce defects, improve readability, and help programmers share knowledge and get to know each other better. The document provides recommendations for different code review methodologies, how to prepare code for review, what reviewers should focus on, ways to improve code quality through refactoring and following best practices like using meaningful names and comments. It also discusses principles like DRY, object orientation, design patterns, and attention to performance and security.

1. Every Programmer Should Know
Code Reviews
Roger Xia
July 2012

2. $ whoami
• Programmer

3. Programming & Code review
• Programming is
– Taking an algorithm
– Choosing a language
– Using that language to implement algorithm and
solve problems
• Code review is
– ?

4. Why?
• Increase Quality & Reduce Defects
• Improve readability
• Share knowledge in team
• Know your workmate better!
• Two Wrongs Can Make a Right
• NOT personal attack!
• NOT architect reviews everything

5. methodology
• Team review (Planned 1-2 hour/week, Clear roles)
• Pair programming (Share knowledge, 1 task)
• Walkthrough (Author leads, reviewers take notes,
higher level)
• Peer review (Asynchronous)
• Gerrit
• Reaction & Ask questions

7. Preparation
• Code Conventions
• Findbugs
• Tested
• Test case

8. Take care of
• naming convention
spelling mistakes
• business logic
• refactoring
• performance
• security (attack, thread safe)

9. Refactoring
• Refactoring modifies software to improve its readability,
maintainability, and extensibility without changing what it actually
does.
• Martin Fowler uses “code smells” to identify when to refactor.
• Boss: "Refactoring is an overhead activity - I'm paid to write new,
revenue generating features."

10. Code smells
• Bad names
• Duplicate code
• Long method
• Large class
• Long parameter list
• Temporary field
• Speculative Generality
• Data Class
• Don’t flood log

11. Use Meaningful Names

12. Meaningful Names
• Class names
– Should be nouns or noun phrases.
– Examples: Car, Account, DataRetrievalService, AddressParser
• Method names
– Should be verb or verbPhrases
– Examples: parseData, deletePage, save
– Methods that return boolean values should sound like question.
– Examples: isAuthenticated, hasNoErrors, isEmpty
• Interface and Implementation
– ICache  LRUCache
– IExport  ExportService
• Constants
– MAX_VALUE
– SEP_COMMA, SEP_SEMICOLON

13. The Art of Readable code
• The book!
• I want to point out:
– Use blank to separate logic block.

14. Comments for complex process,
algorithm, reasons

15. Aiming for simplicity
• Do one thing in a function (simple responsibility)
• Have no side effects.
• Prefer exceptions to return codes.
• Format your code.

16. DRY -- Don’t repeat yourself
• Duplicated code should be avoided.
• Object Orientation, Abstract!
• Design pattern!

17. OO Principles
• Simple responsibility principle: Class should have one and
only one reason to change.
• Encapsulation: Modules should not know internal details of
objects it manipulates.
• Polymorphism -- Liskov’s substitution principle: A subclass
can be used as an argument where a base class is expected.
• Open-closed principle: Class should be open for extention,
but closed for modification.

18. Design Patterns

19. Pay Attention to Performance
• JAVA: JVM usage
– Don’t create object in loop
– Use ArrayList, HashMap etc as opposed to Vector, Hashtable etc
(synchronized) where possible. Even better is to use just arrays
where possible.
– Set initial capacity of a collection (e.g. ArrayList, HashMap) and
StringBuffer/StringBuilder appropriately.
– Concurrent Collection, Lock
– Lazy load or multi-threading where applicable.
– Cache (LRUCache, Distributed Cache)

20. Pay Attention to Performance

21. Pay Attention to Security
• Sandbox (security manager, access manager, Classloaders, policies)
• Scope: Access modifier to help protect your classes, methods, fields.
– public, protected, private, package
– Exceptions: object serialization, reflection,
• Immutable class
– final
– String
– Insecure direct object reference of mutable object
• Type safe
– Casting
• Thread safe
• OOM (static), file description handler, release resources (File, DBConnection)
• SQL injection
• Single point of failure

22. • secure code

23. Have Fun and win
http://rosettacode.org/wiki/Rosetta_Code