1. THE ART OF GIVING AND
RECEIVING CODE REVIEWS
Alex Hill (Imperial College London)
alex.hill@gmail.com
@alexhillphd

2. Defect finding
● In a software-maintenance organization, 55% of
one-line maintenance changes were in error
before code reviews were introduced. After
reviews were introduced, only 2% of the changes
were in error.
● In a group of 11 programs developed by the same
group of people, the first 5 were developed
without reviews. The remaining 6 were developed
with reviews. After all the programs were released
to production, the first 5 had an average of 4.5
errors per 100 lines of code. The 6 that had been
inspected had an average of only 0.82 errors per
100. Reviews cut the errors by over 80%.
● A study of an organization at AT&T with more than
200 people reported a 90% decrease in defects
after the organization introduced reviews.

3. Further motivation
1. Learning opportunities
2. Future proofing:
● Increase your bus factor
● Increase your Hawaii factor
● Ensure code is readable
● Maintain code standards
Increase your bus factor

4. Review < 400 lines of code at a time
Defect density = number of defects found per
1000 lines of code.
Source: Cisco review study, https://www.ibm.com/developerworks/rational/library/11-proven-
practices-for-peer-review/

5. Review < 500 lines of code per hour
Source: Cisco review study, https://www.ibm.com/developerworks/rational/library/11-proven-
practices-for-peer-review/
Defect density = number of defects found per
1000 lines of code.

6. Use checklists
Are there unit tests?
Does it follow SOLID principles?
Do you understand it?
Are there integration tests?

7. Use checklists

8. Code reviews as dialogue
Source: https://m.xkcd.com/1833/

10. Understanding defensiveness

14. http://ragegenerator.com/pages/comic/sql-code-reviews

17. Minimising unneccessary conflict
● Have clear code conventions
● Automate wherever possible:
– Use a linter
– Unit tests
– Continuous integration
● Author reviews first

18. Conflict resolution styles

19. Lower defensiveness
Raise ego

20. As an organisation we can...
● Pair program
● Discuss tasks prior to implementation
● Never silo codebases
● Emphasize teamwork
● Evaluate the code, not the coder

21. ● Use ‘we’ instead of ‘you’
e.g. “You should have re-used this function” →“We could re-use this function”
● Say ‘thank you’
● Raise code by a grade or 2, no more
e.g. C → B+, B → A
● Ask questions
e.g. “We could re-use this function” → “Could we re-use this function?”
● Justify requests
e.g. “Rename this to `getReportsWithFormattedDate`” → “Could we rename
`getReports` to `getReportsWithFormattedDate`, to make it clear that the
dates will already be formatted when it returns?”
As a reviewer we can...

22. Give positive feedback!
• “This is a cool library you found”
• “This refactor makes a lot of sense”
• “This is really easy to read”
• “I didn’t know this function existed,
thanks for bringing it to my
attention!”
Source:
http://geekandpoke.typepad.com/geekandpoke/
2010/11/how-to-make-a-good-code-review.html

23. As an author we can...
● Practice the ‘as if’ technique
– How would I respond if I were grateful for the
feedback?
– How would I respond if I were <Role model>?
– How would I respond if this code was not mine?
● Say ‘thank you’
● Annotate your review first
● Solicit feedback with specific questions

24. ● Optimise reviewer effectiveness
● Minimise unneccessary conflict
● Understand feelings of ownership
● Nudge towards collaboration
● Be nice to each other
Summary