TL;DR notes from articles I read today.

How to do good code reviews

• Set measurable goals and capture metrics, but do not set too many. Good code must work as intended, have high readability, and perform optimally.
• Ask deep questions and confirm your understanding at each step, until your knowledge of the code is as good as the developer’s.
• Address everything you may think relevant, not just what you were told.
• Look for code that is repeated, non-modular, or flouting standard conventions.
• Avoid reviewing code for more than 60 minutes or more than 400 lines at a time. Increase the frequency of reviews so you can take time to identify the best solutions.

Full post here, 6 mins read

Why consistency is one of the top indicators of good code

• Consistency can be defined as both conformity and uniformity.
• Consistency in code allows you to make accurate assumptions and predictions about its behaviour and implementation.
• Small continuous improvements in the approach of doing things can introduce a great inconsistency in the overall code over time. Try to ensure complete adoption of the new approach, phasing out the old one entirely.
• Where both approaches must remain, at least preserve consistency within verticals or modules.
• Name things consistently (so that similar objects sound similar and dissimilar ones sound different) and let the name reveal context, behavior, and intent.

Full post here, 6 mins read

Finding the time to refactor

• Think of programming as writing code - that works, is easily readable and easy for other developers to modify and extend in the future.
• In test-driven development, get used to thinking of a 'red-green-refactor' cycle. The green state ensures code passes tests, but the refactor ensures it stays clear and maintainable.
• Make refactoring integral to every work schedule. Take a few minutes to clean up code, as soon as tests pass, with better names and extracting private methods and classes, etc.
• Whenever adding a feature or fixing a bug, if you have to modify any piece of code that was hard to understand, refactor it right there and then.
• When you try to introduce something new and the existing design does not work, refactor the design so the new addition is easier to make.

‘Make the change easy, then make the easy change.’ - Kent Beck


Full post here, 4 mins read

Get these notes directly in your inbox every weekday by signing up for my newsletter, in.snippets().