Code Review Best Practices - Formatting Standards

Many development teams spend an inordinate amount of time arguing over styling and formatting preferences, such as:

• Whether to use single quotes or double quotes
• Whether curly braces go on the same line or the next line
• How to wrap long lines of code

Although these preferences are somewhat subjective, there's something to be said for consistency. Imagine you're reading a book where one page is double spaced and the next is single spaced. On one page, important terms are bolded, and on another page, important terms are underlined. As a reader, those types of inconsistencies can get between you and the content of the book. Likewise, in code, these types of styling and formatting preferences do make a difference.

Since styling comes up frequently during code reviews, it's a good idea to have a strategy in place for dealing with it. Here are three levels of maturity for dealing with code formatting on a development team.

Code Review Best Practices - Review Everything

Welcome to the second part in a series on best practices for code reviews. Last time, I explained why I believe it's important for everyone on the team to chime in on code reviews -- rather than having a single gatekeeper, it's important for everyone to share that responsibility.

Today I'm discussing the flip side of the coin -- everyone's code should be subject to review. I believe even the technical leads should submit their code for review. Of course, it's tempting to let their code slip by because, hey, if they don't write code that passes the team's standards, then who the heck does?!

But there are actually very good reasons to subject even the technical lead's code to review. Here are three of them: