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