6 code review best practices for a happier codebase and team

6 code review best practices for a happier codebase and team#

You can’t do an effective code review if you’re rushing through too many lines of code. Quality is certainly more important than quantity when you’re reviewing lines of code. If you spend too much time reviewing code in one sitting, your review will become less effective and less attentive (which defeats the purpose of getting a fresh pair of eyes during code review).

How you manage your review time may depend on your situation, but some general guidance is:

• Limit your review to 200-400 lines of code at once
• Don’t spend more than one hour at a time reviewing code
• Plan for 3 seconds of review time per line of code

The type of feedback you provide is crucial in building rapport with your team. You should make the effort to ensure that your feedback is helpful and comes from a well-intentioned place.

Constructive feedback will help a code author get closer to merging their source code. This doesn’t mean you should be solving or fixing their code for them. But your feedback should point them in the right direction, rather than toward a void of confusion.

An example of how not to give feedback: “This code is wrong. Why did you do this?”

Always explain the “why” behind your feedback. If you suggest an alternative line of code, you’d be depriving the code author from a learning opportunity if you didn’t explain why it might improve their original code. Explaining the “why” also reduces the need for follow-ups, by giving the author the necessary context to incorporate your feedback.

Even if you think you can cover all the bases, checklists can help streamline your code review and focus your priorities on what matters most. You could have a personal code review checklist, but ideally, you’ll have a code review checklist that’s followed consistently across the development team.

A code review checklist might contain the following considerations for the new code:

• Readability: Is it clear what the code is doing? Does the code have meaningful naming conventions and code comments?
• Performance: Does the code take too long to run? Is there a simpler solution that would be worth implementing?
• Reusability: Does the code follow best practices such as the DRY principle?
• Test coverage: Are there any edge cases that are unaccounted for?
• Maintainability: Does the code follow best practices such as loose coupling and high cohesion?

Code reviews would be unnecessarily tedious without code review tools.

Some popular code review tools are GitHub, GitLab, BitBucket, and Gerrit – but there are many others as well. Each tool has different features, but ultimately, they can all serve to streamline code reviews and easily integrate them into your team’s software development workflow.