How I approach a code review.

1. How I review code
@erikEcoologic
Github: erikEcoologic

2. Too big?
• Ask to split it (:
• I will make frequent, small, releases so that I do not
impede the progress of others (Programmer’s Oath n.4)

3. Read
• Architecture agreed in advance?
• The actual task description (referenced in the MR title) -
ideally
• The MR title and description
• The commit messages…

4. Commit messages
• Fix… (tell what)
• Refactor… (tell what, use multiline?)
• S1234 As a user I want to do this (include specs for this)
• S1234 As a user I want to do that (include specs for that)
• Cleanup (green specs)
• —
• Possibly avoid commits with: WIP, “solved conflicts”, “merged x” etc
• git reset --soft origin/master # Careful - Git stash; green specs; Bisect

5. Reading the Code
• Scroll and get an idea
• Start from the specs
• Follow the code like a parser
• Global review

6. Specs
• What you expect from the title (core functionality)
• Some unit tests
• Internals are not mocked
• betterspecs.org
• I will produce, with each release, a quick, sure, and
repeatable proof that every element of the code works as
it should (Programmer’s Oath n.3)

7. Production Code
• Security!!
• Readability
• Doesn’t make you feel stupid
• I will continuously ensure that others can cover for me,
and that I can cover for them (Programmer’s Oath n.7)
• Simplicity
• Can you think of a simpler way?

8. Good Code
• Agile principles (e.g. DRY, IAGNI)
• OO principles (e.g. SOLID, Demeter)
• Design Patterns (e.g. Service)
• Code smells (e.g. Shotgun surgery)
• Bad practices (e.g. Comment what)
• The code that I produce will always be my best work. I will
not knowingly allow code that is defective either in behavior
or structure to accumulate (Programmer’s Oath n.2)

9. Naming!!
• Follows company conventions
• Follows project conventions
• Consistent namespacing
• Specific, limited responsibility
• It does what it says
• Is clear what it does
9

10. How to comment
• Ask questions
• Suggest, don’t impose yourself
• Back your comments with links
• Everyone learns, objective comment
• In depth explanation
• Create a common language
• I will never stop learning and improving my craft (Programmer’s Oath n.9)
• Agile: People over tools, be kind
• Talk in person, but make sure you’re chill
• Mention the good stuff too

11. More Resources
• blog.jetbrains.com/upsource/2015/07/23/what-to-look-
for-in-a-code-review
• blog.cleancoder.com/uncle-bob/2015/11/18/
TheProgrammersOath.html
• Clean Code Book - Robert C. Martin
• Refactoring Book - Kent Beck
• Agile Manifesto

12. Thank You
Twitter: @erikecoologic
Github: ErikEcoologic