Five points stopping us from becoming a great code reviewer?

A code review is when one or more team members check the work of another coworker. This entails inspecting modifications to the source code before they are incorporated into the codebase.

Code reviews are crucial for improving code quality, catching bugs and technical debts at an early stage and making your codebase more reliable. If you take it seriously, you can catch security violations as well. Furthermore, they assist coders with creating relationships and working more efficiently together.?

90% of the code reviewers commit one of these mistakes, read below about those mistakes and solutions to those.

Reviewing using memory power, not defined standards

Most organizations have a defined standard for code review but small organization relies on the reviewer's capabilities and memory power. This tends to result in different outcomes for each review. A violation identified in a changeset/commit may be ignored in a subsequent review.

If you are a startup or small organization, the first step towards effective code reviews is to create a set of defined standards and do a freshness review periodically. The reviewers will be benefited from this as there are fewer chances of missing something and developers have an idea in advance how their code will be evaluated.

If you work on .NET, then you can use Microsoft's predefined guidelines or maybe use their Code Analyzers or Stylecop Analyzers. If you work on Python, you can use Pylint or Codiga.

Reviewing because it is part of the job

What do you do when you get a changeset with 1500 lines of code review? Do you start reviewing it immediately and only stop once you reached to toe? Expert says that the human brain can't focus on anything beyond an hour.

Set realistic expectations and do not review more than 400 lines of code at once. If possible, line it up for another day or perform a review of the next 400 lines after 30 minutes.

Creating a hostile culture

Code Reviews must help the developers to become better. It is not a bashing ground or about finding their incapabilities.

The comments/annotations on code reviews should be meaningful, describing what's wrong and what is expected. If you have defined standards, reference to the standard number or link to it will also do it. Double-check the tone of the comment, it should not be harsh.

A positive tone, encourages the developer to understand the importance and greater chances of improving, whereas a negative tone will only demoralize him and will mitigate the chances of improving.

There must be after-review support as well. A note to the developer (in annotation or IM or Email) that if he needs any support on fixing or understanding is required, you are available and will do the wonders.

Only focusing on violations

Generally, violations are caught and documented in the code reviews, but occasionally we notice an extraordinary piece of code which qualifies to be state-of-the-art, creative, effective and optimized.

If you ever come across a code, which you think is a great piece of work, do write a note of appreciation, such as

"Well done for using x functionality of the newer version."

"Well done for taking care of all possible user input threats." or

"I can see that you are using unusual email validation which treats + sign as an acceptable character. This is a new feature and I would recommend your solution to become the new standard for email validation.

Not measuring the improvements

One of the mistakes we all do is that we review and forget. All code reviews must be documented and based on that data a report like the number of issues per 100 lines of code, or the most violated standard can be created.

We can use these reports to train and educate to improve the code base further.

Conclusion

Numerous choices must be made when reviewing code, such as what to focus on, how to provide feedback, and when to approve. It is unimportant that you accept my selections. Simply recognise that there are alternatives.

Nobody can give you a bible for a flawless review. The strategies that work best will be determined by the personality of the code author, your relationship with them, and the culture of your team.

#codereview #coding #positivevibes #technicaldebt #developer #postivemindset #githib #tfs #azuredevops