Top 10 Code Review Tips & Tricks

Note: This blog post transferred from my OLD BLOG and was originally posted in 2007.

Working closely with a lot of Agiled Teams i discoverd that new people for agile process have some issues related to the purpose of coding review process and code review meetings . lately i’ve beeen coaching a new .net development team on Agile , and i came across the same situation again , with the same old question .. What is Code Review for ?

Code Review have 2 main purposes :

First to make sure that the code that is being produced has sufficient quality to be released. In other words, it’s the acid test for whether the code should be promoted to the next step in the process.

Second as a teaching tool to help developers learn when and how to apply techniques to improve code quality, consistency, and maintainability. Through thoughtfully evaluating code on a recurring basis, developers have the opportunity to learn different and potentially better ways of coding.

To Achieve the best case for code reviewing scenarios , i created a simple top 10 techniques list that helped me alot through the projects i worked in (as developer,Team Lead,Architect or even System Designer) to enhance and accelerate the code reviewing process for my code .

1. CodeReview.Checklist.Add().

Start creating your own checklist of the areas code reviews will cover , you may follow the code slandered for the company to start creating your checklist, go through your code with the checklist and fix whatever you find. Not only will you reduce the number of things that the team finds, you’ll reduce the time to complete the code review meeting—and everyone will be happy to spend less time in the review.

2. CodingStandards.Update().

One of the challenges that a developer has in the company with combative code review practices is that they frequently don’t know where the next problem will come from. rapidly updating the coding standards will help developer to learn from past lessons and minimize the opportunity of having the issue in next review meetings .

3. Developer.Me != Developer.Code .

Remember Development is about creativity . if you have some bugs in your code this doesn’t necessary means you are a bad developer . your colleagues who are reviewing the code generally aren’t trying to say that you’re a bad developer (or person) by pointing out something that you missed, or a better way of handling things. They’re doing what they’re supposed to be doing by pointing out better ways. Even if they’re doing a bad job of conveying it, it’s your responsibility to hear past the attacking comments and focus on the learning that you can get out of the process. You need to strive to not get defensive.

4. Developer.Code.UnitTest().

Always remember writing comprehensive unit tests will save a lot of the time that we would traditionally spend reviewing proper functionality . Instead, we focus on improving the functionality of code that has already been shown to work

5. Developer.Code.IsObjectOrianted.

Make sure all the time you are following the best practices of object oriented, every single piece of code can be done in usual old structured way BUT this is not the way we think , refractor your code to be object oriented code .

6. Developer.Code.DesignPatterns.Add().

Whenever possible use commonly known design patterns that suits your situation, design patterns are widely known between developer community and gained their trust and confident and had been tested on a lot of situations proving its fitness . so be in the safe side and use it if you need it.

7. Developer.Code.IsComplex.

Think agile , keep it simple all the time , assumptions leads to complex design and complex code . focus on the current problem and use the shortest way to solve it this will reduce your code complexity and in turn the probability of bugs.

8. Developer.Code.HandleExceptions() .

The code required to handle exceptions ” Try/Catch .. ” is the cheapest code in the world , it will cost you nothing , so don’t forget to handle your code expected and generic exceptions .

9. Developer.Code.Build.IsFreeOfCodeAnalysisWarning .

The ideal case for your code is to build probably without any code analysis warnings , always remember code analysis warning is your friend, it help you to avoid future bugs and security vulnerabilities that might defect your code. So pay attentions to them .

10. Developer.Code.IsClean .

Follow the naming conventions as your company coding standards refer. Keep the code files outline neat and clean. Remove any redundant code or comments . Organize your code in regions with descriptive names . Avoid grouping multiple types in one code file. Use XML tags for documenting types and members. Simply learn the art of beautiful code .

Hope this Helps

Ahmed