Thoughts on code reviews

Developing software can get expensive when bugs are found. The cost of fixing a bug will vary depending on when the bug is found in the SDLC. Early on in the development of code, it is a minimal cost. Should the bug be found after the code has been deployed into production after a couple of months the cost is now high.

So if code reviews are part of the SDLC we can have due diligence that will minimize the risk of rogue code getting into the production environment. As a developer would you rather fix existing code or have the challenge of writing new.

With that in mind here are some of my thoughts about code reviews.

Triage first look

1. The naming of classes method variables. There should be a standard for naming. For example, when naming Classes and Methods use Pascal case. With variables use Camel Case.

For example:

Class: Member

Method: GetName

Variable: firstName

 

Names should also be meaningful.

2. Does project compile with no errors or warnings? Is it possible to download the code from source control and compile the solution without errors or warnings?

3. Are methods no longer than 40 lines. Greater than 40 lines and it can become difficult to read and understand.

4. Is the code readable, are there comments? Are agreed standards being used. As you read the code is it obvious as to what it is doing. Have this mentality. In 6 months’ time, if a mad crazed programmer was having to make a modification to the code I am writing would they be coming after me to stab me in the back?

5. Is there code reuse. Is it possible to reuse the code?

6. Are objects closed? If the code opens a database connection, is that connection closed when it is no longer needed.

7. Is there unreachable code?

8. One entry point, one exit point.

9. Is there exception handling. Does the code handle exceptions gracefully? Is there sufficient information captured so a developer can investigate. For a user do they see a meaning full error message? Is it possible to continue?

Functionality

1. Is there trace/logging? When the code is out in production we do not have the luxury of setting breakpoints and looking a the value of an object. Logging events in code will be invaluable to understand what is happening in production.

2. Are there unit tests and do they pass? Unit tests are a great way to quickly identify if code is performing as expected.

3. When the code is run for given input is the output the expected value? This includes exceptions and fail states?

4. Is there input validation? Stop a user entering data that will cause code to fail. Check for legal input, this is easier to check that all the inputs that are not allowed.

Long term

1. Demonstrate code. When you get a chance demonstrate code to colleagues and ask for feedback.

2. Webinars. Many companies and individuals are creating videos to explain how to code. This can be a free and easy way to learn new techniques.

3. Training. Take advantage of training. This will expose you to different ideas. Sometimes taking a class in a language that is new can introduce new ideas for solving problems.

4. Read articles, blogs etc. By reading how other people have solved problems and can implement these ideas into our own code.

5. Talk to colleagues. No one person knows everything. Talk to colleagues about how they would solve a problem. Maybe they have already solved the problem or something similar.

This is by no means a comprehensive list and it is written from the perspective of someone who is coding in the Microsoft stack. The code review should be a living process. Yes, there will be times when something gets out into the wild.

One thought on “Thoughts on code reviews

  1. Pingback: Dew Drop - October 16, 2017 (#2582) - Morning Dew

Leave a Reply