Category: code review

Code reviews are an essential practice in any software development team. It allows you to keep your code consistent. It also allows other developers to become familiar with your code changes. Embracing code reviews helps keep your code base healthy.

To improve your code review process, you can do the following:

1. Document your code style
2. Allow more than 1 developer to perform the code review
3. Keep your code changes small

Document your code style

If you don’t document your code style guideline, it is very difficult to keep your code consistent. Some developers might use 2 spaces to indent, others might use 4 spaces to indent. If you have a code style guideline available to all developers, it is easy to enforce it. In addition to be enforced, it is easy for programmers to follow it. You don’t have to open up different files to see the current style guide. You should go to the official style guide for your team or company.

The Python community has documented their code style guide. They created a code style guide under PEP8. One of those conventions is to use 4 spaces per indentation level.

Google has a Javascript style guide. One of the conventions found in the Javascript guide is to always use the keyword var to define variables. Another convention in that document is to always use semicolons.

The Ruby community has also created a style guide. It is hosted at Github and you can see the source here. In contrast to the Python community, they prefer to indent with 2 spaces. See the following example taken from their style guide:

# bad - four spaces
def some_method
    do_something
end

# good
def some_method
  do_something
end

As you can see from these examples, there are code styles available to help us start with our own documentation. If your team does not have their own style guide, then you can at least document that you will follow Google’s Javascript style guide for example.

Allow more than 1 developer to do the code review

After you have your style guide in place, it is very easy to perform code reviews. It is very important that more than 1 developer in your team can review code changes. Sometimes the team lead might be busy or not available and you don’t want your team waiting on that person. They can go to another developer to do the code review. I believe this is a big problem with a lot of open source projects. Some of these popular projects have few developers in charge of the code reviews and many times the pull requests are not handle in a timely manner.

Keep your code changes small

It is easier to code review 1 or 2 files than to review 20 files. If you have a large number of files, the code review takes a very long time to complete. It is recommended to keep your code changes small. For example, if you have database, business logic, and HTML changes, you can break those changes into 2 or 3 code reviews.

Conclusion

If your team performs code reviews in a daily basis, your code base will stay consistent and hopefully bug-free. Based on my experience as a software developer, having a code style guideline, rotating the person performing the code review, and keeping your code changes small, will allow your code review process to be fun and enjoyable.