Effective code reviews

1. Effective
Code Reviews
William Deurwaarder
30th of May, 2015
NextBuild

2. Think profit-based, not cost-based.
TomTom devices
2

3. Think profit-based, not cost-based.
TomTom products
Maps
Navigation
Traffic
Fleet-management
Fitness
3

4. Think profit-based, not cost-based.
Introduction
• Theory
• Creates awareness, explains philosophy
• Defines “defect” and explains its impact
• Practice
• How to improve the efficiency of reviews?
• What is role and mindset of author and reviewer?
• How to execute reviews?

5. Think profit-based, not cost-based.
Perfect code
What is perfect code?
• Working
• Readable
• Maintainable
• Extendable
• Elegant
• Simple and clear
• Well documented
• …
Easy to recognize, hard to describe

6. Think profit-based, not cost-based.
Not so perfect code
Why is real code not so perfect?
• Time-boxed
• Lack of experience
• Change on change
• Edge cases
• Built on legacy
• Mindset author (problem solving, result oriented, pragmatic, …)
• Multiple authors (own mind, no machines)
Easy to describe, hard to fight

7. Think profit-based, not cost-based.
Definition of defect
What is a defect?
• Highly unlikely defects
• Race conditions
• Timing issues
• Extreme load
• Trivial defects
• Subjective term
• Hard to predict impact of a defect
Defect: anything that may cause any additional cost later on

8. Think profit-based, not cost-based.
Cost of defects
Cost to fix defect grows exponentially
Consider 4 stages: design  develop  test  production
Every stage adds additional cost factor of 10
• code review instead of test: 10x cost savings
• code review in stead of production: 100x cost savings
Finding/fixing defects early is always faster and
cheaper than not finding or not fixing them

9. Think profit-based, not cost-based.
Cost of defects
1 single defect will pay for 100
99 defects never ever causes a problem
1 single defect causes a problem in production
Question is: which one?
No significant additional cost fixing 5 or 50 defects
Building, Reviewing, Testing, Deploying
Fix ALL defects that you can find (no priorities)

10. Think profit-based, not cost-based.
Fix ALL defects
What happens next?
• No trivial defects any more
• No discussion on minor and major, just defect
• No subjective reasoning
Cleaner and more useful statistics as well
• Code gets higher quality and is easier to review
Increased developer pride, reduced ‘broken window’ effect

11. Think profit-based, not cost-based.
Change your thinking!
The cost of fixing everything is small,
and the profit is much higher than the cost
Fix all defects that are found
• Ensure defects that cause issues are fixed
• Ensure defect that pays for all other defects is fixed
Think profit-based, not cost-based

12. Think profit-based, not cost-based.
Statistics
This is about applied statistics
Good engineers respect statistics
You are an engineer… respect and obey statistics!
Know: Many defects will never cause an issue if left unfixed
So: Fixing an individual defect does not necessarily reduce cost
And: Some (unlikely) defects will lead to great cost if left unfixed
But: You cannot tell which defect will cause an issue
Not about individual defects or reviews, about applying this
practice continuously -> benefits

13. Think profit-based, not cost-based.
Theory summary
Defects enter our code for a lot of reasons
Defect is anything that cause additional costs
Cost to fix defect grows exponentially
Fix ALL defects
Think profit-based
It is all about statistics

14. Effective
Code Reviews
(Practice)
William Deurwaarder
30th of May, 2015

15. Think profit-based, not cost-based.
Introduction
• Theory (previous session)
• Creates awareness, explains philosophy
• Defines “defect” and explains its impact
• Practice
• How to improve the efficiency of reviews?
• What is role and mindset of author and reviewer?
• How to execute reviews?

16. Think profit-based, not cost-based.
Improve quality
How can reviews address mentioned issues?
• Reviewer has different goal so different mindset
• Author solves the problem
• Reviewer checks code quality (guardian)
• Solution fits context
• Solution adheres to good practices
• Reviewer is not bothered by time (dead-line)
• Reviewer looks at code from different angle
Code review is an easy tool to increase quality

17. Think profit-based, not cost-based.
Increase efficiency of reviews
What can be changed to become effective?
• A: Ensure changes are ready (static code analysis, annotate)
• A: Limit number of reviewers (default is 2)
• R: Find as many defects as possible (time-boxed)
• R: Be thorough (address everything that catches the eye)
• Sharing knowledge
• Establish team-culture (abbreviations, code duplication)
• A: Fix ALL defects (no priorities)
• R+A: work together, same goal (peers)
• No need to defend yourself: “finding more defects is better”

18. Think profit-based, not cost-based.
Role and mindset author
Problem solver – solution driven – time aware
• Prepare review (static code analysis, review yourself, annotate)
• Remarks aim to increase quality of code
• not to discuss author’s ability to code (no defense)
• Normally answer questions with comment in code
• Review will almost never be read again, code will
• Address ALL found defects (no priorities)
• minor defects take very little time to fix (no discussion required)
• Handle clearly incorrect remarks respectfully
• Discuss off-line; comment in code?
• Author is end responsible for changes and quality

19. Think profit-based, not cost-based.
Role and mindset reviewer
Guardian – quality driven – time-boxed
• Execute review promptly (do not become a bottleneck)
• Make only remarks to improve quality of code
• Do not offer solutions or “better alternatives”
• Do not “educate” the author (off-line, coaching)
• Thorough, relentless AND respectful
• Can never find too many defects (slow pace)
• Avoid religious wars, no personal flavors, only technical
• Explain why something needs improvement
• Ignore amount of rework to fix defect
• Always re-review after author updated code (prompt)

20. Think profit-based, not cost-based.
Tone of review
• Be neutral, explain your interpretation
• Be aware of different mindset
• Be respectful (no SHOUTING!, no telling, no lecture, use keywords)
• Explain with reasoning in case technical solution needs
improvement
• Single problem may have multiple solutions
• Search for reasons of unclarity (do not ask why to quickly)
Remember goal
• author is responsible for code quality
• reviewer helps author to establish level of quality
• working together as peers to improve quality

21. Think profit-based, not cost-based.
Examples
- What is this about?
+ The context is unclear, can you explain…
- This sucks…
+ This causes issues like x, y, z…
- Did you read the documentation at all?
+ The documentation specifies x rather than doing y…
- You should implement this completely different!
+ Doing x causes issues y and z in…
- NO, NO, NO…
+ This causes issues x, y, z in…

22. Think profit-based, not cost-based.
Defect remark strategy
• Gather context information (design, user-story, JIRA-issue)
• Focus on changes, keep eye on context
• Search for patterns and inconsistencies
• Check complexity (bang-for-buck, keep-it-simple-stupid)
• Let unconscious mind help (bell ringing -> investigate)
• Act like logical compiler (do not interpret code -> read code)
• Ask if something is unclear (comment should be added)
• Mark all style defects (diminishes quickly, static code analysis)
• Code removal – check correct and complete
• Use checklists

23. Think profit-based, not cost-based.
Practice summary
Author is responsible for code quality
Reviewer helps author to establish level of quality
Author and reviewer work together as peers
Reviewer is thorough, relentless and prompt
Author fixes all found defects
Reviewer review all changesBe polite

24. Think profit-based, not cost-based.
Code review rules
Time-boxed period to polish the code

25. Thank you
Any questions?
William Deurwaarder
Head of Developer Relations, TomTom
E-mail: william.deurwaarder@tomtom.com
Website: http://developer.tomtom.com

26. Think profit-based, not cost-based.
Code-review figures
Indication of important figures
• Minimum review time per session 5 minutes
• Maximum review time per session 60 – 90 minutes
• Maximum review size per session 200 – 400 LOC
• Default number of reviewers 2
• Maximum inspection rate 300 – 500 LOC / hour

27. Think profit-based, not cost-based.
Checklist for code-review (1/4)
Check consistency with design (see change in bigger scope)
• Verify edge-cases
Check consistency interface changes
• Scope changed (private to public; why?)
• Order of parameters (same in all methods)
• Symmetrical methods
• Use of default parameters
• Implementation details leak through in interface
Check level of containment (increasingly risky, increase scope)
• Within method
• Within private methods
• Within public class methods
• Within public interface of system (NavKit)

28. Think profit-based, not cost-based.
Checklist for code-review (2/4)
Check complexity
• Keep algorithms clean (no exceptional cases)
• Verify edge-cases… throw exception in stead?
• Try what-if scenarios
Check exception handling
• Is exception caught?
• Adheres to exception handling policy
• Exception handling aligned with surrounding code
Check readability, clarity (decrease time to understand code)
• Remove code duplication (extract method)
• Check functionality of method (reduce size of method)
• Add comments to increase readability

29. Think profit-based, not cost-based.
Checklist for code-review (3/4)
Check includes/imports (needed? correct?)
Check NULL-pointer behavior (can reference be used?)
Check const-behavior (consistent, no const_cast)
Check algorithms for one-off errors
Check resource leakage (memory, file handles, …)
Check multi-threading behavior
• Race-conditions
• Dead-lock situations
Check usage of members and local variables
• No state duplication (only for measured performance improvement)
• Superfluous
• No re-use of variables with different meaning

30. Think profit-based, not cost-based.
Checklist for code-review (4/4)
Check type-casts (discourage them)
Check surrounding comments
Check correct usage of libraries (STL, OSAL, …)
Check “early” optimization
• Is measurement in place?
• Is there comment with explanation?
Check use of deprecated code
• NavKit-examples: NavKitEnvironment, Tdes, CString
Check use of discouraged patterns
• Singleton
Check if tests exists