Tips For Code Review

In general code, review helps you to :

• Identify and catch bugs
• Spread knowledge of the code base throughout the team
• Get new people up to speed with the ways of working
• Ensure code is readable and maintainable

We will go more deep in code review by listing the tips below :

• Everyone should code review: Some people are better at it than others. The more experienced may well spot more bugs, and that’s important. But more important is maintaining a positive attitude to code review in general

Review all code

• Review everything then nothing gets missed. When you review all code you ensure that you have a well maintained product

Code review often and for short sessions

• Better to not review code too quickly, also not reviewing it for too long in one sitting. When people engage in any activity requiring concentrated effort over a period of time, performance starts dropping off after about 60 minutes. On average the time of code review should be 10 to 15 min per day.

• Code reviews in a reasonable quantity, for a limited amount of time, results in the most effective code review.

Always be patient and relook if required

• Sometimes, developers do not accept suggestions and keep debating.

• A code reviewer may not know the exact context and challenges when the code was written.

• A code reviewer should understand all the points being made by the developer without losing patience. Furthermore, to make the point crystal clear, a code reviewer can explain the points on a paper or on a whiteboard by comparing the developer’s approach vs the code reviewer’s approach.

Capture the enhancements and technical debt

• It is quite likely that some code review suggestions cannot be implemented during the current release. However, a code reviewer should ensure that all accepted recommendations are clearly documented in a shared code review document so that these are implemented at an appropriate time in the future.

• Finding enhancements during code reviews is more efficient than finding separately at the end of the project. But most companies do enhancement at the end of the project or in other releases of the product.

Practice lightweight code reviews

• To fully optimize your team’s time and to effectively measure its results, a lightweight process is recommended.

• SmartBear study of Cisco Systems found that lightweight code review takes less than 20% the time of formal reviews and finds just as many bugs! Formal, or heavyweight, inspection averages nine hours per 200 LOC.

Do code reviews as soon as you see the request

• Even if it looks like a large review, try to make the first pass as soon as possible. Your coworkers will be grateful, and their goodwill will help you grow faster as a reviewer. It isn’t always easy to do code reviews immediately, especially if they change a lot of code or it takes a long time to start up your app. If you find yourself procrastinating on code reviews these tips might help you get started faster: Set a time limit, like half an hour. On your first pass, spend that half-hour trying to understand the change and writing down questions. If at the end of the time limit you think you can approve the change, approve the change. If you aren’t ready, send the author any thoughts or questions you have so far, and schedule and commit to a time when you intend to do a more detailed pass and approve or request changes.

• Keep two separate repositories on your machine, one for your own changes and one for changes you are reviewing. This way, compiling your coworkers’ changes won’t destroy compile artifacts associated with your own changes.

Always give approval, unless you can prove that there is a bug

• When you suggest changes, assume that the author can handle the changes. Slowing them down to wait for the second round of code review is almost never worth it, especially if the changes are simple things like renaming variables or extracting a duplicated method. If you make authors wait longer because of style, the code will get worse in the long run. Slowing down changes makes people reluctant to submit small changes that clarify and clean the code. If you don’t feel qualified to give approval, say it in those words and come up with a plan to get the right person to look at the code. When you forget to click “approve” the author of a change doesn’t know if you forgot, or you think the code is broken, or you don’t care if they are blocked. Help them feel your good intentions by being very clear about what the next step is.

• Review at least part of the code, even if you can’t do all of it, to benefit from The Ego Effect

• Imagine yourself sitting in front of a compiler, tasked with fixing a small bug. But you know that as soon as you say “I’m finished,” your peers — or worse, your boss — will be examining your work. Won’t this change your development style? As you work, and certainly before you declare code finished, you’ll be a little more conscientious. You’ll be a better developer immediately because you want the general timbre of the “behind your back” conversations to be, “His stuff is pretty tight. He’s a good developer;” not “He makes a lot of silly mistakes. When he says he’s done, he’s not.”The Ego Effect drives developers to write better code because they know that others will be looking at their code and their metrics. No one wants to be known as the guy who makes all those junior-level mistakes. The Ego Effect drives developers to review their own work carefully before passing it on to others. A nice characteristic of The Ego Effect is that it works equally well whether reviews are mandatory for all code changes or used just as “spot checks,” like a random drug test. If your code has a 1 in 3 chance of being called out for review, that’s still enough of an incentive to make you do a great job. However, spot checks must be frequent enough to maintain the Ego Effect. If you had just a 1 in 10 chance of getting reviewed, you might not be as diligent. You know you can always say, “Yeah, I don’t usually make that mistake.” Reviewing 20–33% of the code will probably give you maximal Ego Effect benefit with minimal time expenditure and reviewing 20% of your code is certainly better than reviewing none.

Document all code review comments

• Document all code review comments in an email, word document, excel, or any standard tool used by the organization. Making a mistake for the first time is acceptable, but it is not a good sign to repeat the same mistake. The code review document helps software developers to cross-check the highlighted issues and avoid making similar mistakes in the future. Additionally, maintaining a code review document is a mandatory part of the Capability Maturity Model Integration (CMMI) level process.

Can be found on Techwebies