Things you need to know about code review

The details provided here are not specific to any programming language, you will find lots of articles which will give you technical specific help to perform a review process but here I am trying to set a context for your thinking, so that you can be a good team player and leader by example, which you may not get from other articles.

1. Add a comment only if you feel like the change which you are proposing will add some value.

Example:

if there is a code like?

for(int i=0;i<10;i++){}

You like the variable j, so you may give a review comment "Use j insread of i".

But you need to ask yourself before adding the comment, does this comment add some value to the source code?

Changing the variable name to j, does not add any value, so you can avoid such comments.

2. Not adding a comment is also a comment.

After reviewing the changes, you found that the changes are good and it is ok to be approved.

But as you have started reviewing the changes and some how you feel like you need to add a comment so that, within the team an impression will be created for you. It is not like that actually, if the changes are fine approve it, and do not search for areas where you could find something, do not force yourself.

3. Respect and be polite

You should show the respect to the fellow engineer who requested the review from you, the comments given should show respect and the comments added should be in a polite language.

Example:?

if there is a code like

string kkppmm = '';

The comment should not be like "hey, change the variable name to 'address' and do not give meaningless silly variable names like this".

The comment should be polite like this "Could you please rename the variable to 'address' which will be more readable and meaningful."

4. Any one can do a review

If you think like only leads can review the source code, it is a myth, actually anyone in your team can review the code irrespective of the designation SE, SSE, Lead etc.

5. Avoid arguments in the comments.

Should not argue in the comments, if the engineer have any concern he should raise the same in the corresponding meetings.

Example:

There is a comment "duplicate function "calculateArea" should be removed",

The reply should not be like "I do not have time now, I will do this only in the next release."

The reply should be like "Time does not permit to perform this change and we will note this and will add to the known review comments section in the release note and will consider the same with the next release".

And you can raise this concern in the meeting.

6. Give priority for the project standards

While reviewing, always give priority for the standards which is set for the project, do not go with your personal opinion. Personal opinion you can raise in the?meetings.

Example:?

The coding standard document says "Use Pascal casing for class names", but you like camel casing, but you should give priority and importance for the standard document.

7. Be generic

The comments given should be completely general and it should not depend on, who has worked, on the code changes.