Code review guidelines for coders and reviewers

 Systematic inspection of computer codes is said to be known as code review process. 

The purpose of this reviewing process is to suspect and fix errors & omissions overlooked in the initial development phase, while improving the overall software quality. 

Code reviews are robust means to improve the quality of codes, set up best practices and to proliferate knowledge. Nevertheless, code reviews can be useless and harmful towards interpersonal relations, when they are not performed accordingly. Thus, it’s vital to pay attention to the coders and reviewers aspects of code reviews. Code reviews require a certain mindset and phrasing techniques to be successful. For an organization to maintain its software development life-cycle, they can either outsour code review services or ask their own team to do so.

Code Review Guidelines - With Respect To Coders

Submissiveness

Coders are also human beings and humans make mistakes. So if humans are writing software then it would definitely have some errors in it. This does not mean that coders remain frightened at all. Instead this means that coders must have a mindset, they can face criticism and rejection as a part of the learning process.

The key takeaway here is to “Be Submissive”. Coders must be ready to accept the critical point of view of reviewers and have a tendency to learn from the mistakes they’ve made.

Insensitive

Coders must understand that “they are not their codes”. If someone has said that your code is not written well, then there isn’t any need to take it personally. You may understand that this criticism can help enhance your technical skills.

Exchange of knowledge & expertise

Coders need to keep this in their minds that reviewing is not a process of just communicating what's wrong and how to make it correct. Instead it's a two way process in which there is an exchange of best practices and expertise between coders and reviewers.

Code Review Guidelines - With Respect to Reviewers

Use I-Messages

Reviewers must formulate their feedback in “I-messages” i.e I suggest, I think, I would prefer etc. Because, in contrast if reviewers would provide their feedback in the form of insinuation and an absolute statement, it would definitely be an attack on the coder. And instead of improving codes, they would find ways to argue with reviewers. 

Feedback on code not on coders

Just keep this in mind all the reviewers around the globe, provide feedback on the codes written by the authors instead of commenting on coders ability. This will result in harsh coders feelings.

Ask Questions 

While communicating with the coder about the code being written, it is recommended to avoid statements and ask questions more often. 

For instance; 

Wrong: “This variable should have the name ‘userId’.“

Right: “What do you think about the name ‘userId’ for this variable**?**“

Conclusion

It is widely being observed that sometimes they are coders who are reluctant to accept any feedback and sometimes its reviewers who provide their feedback in form of insinuation and an absolute statement, therefore both must be concerned about the mutual gain and not hurt anyone’s feelings. Only this way codes can be reviewed effectively, teams would be able to learn and organizations will be able to reap productivity.