Code Review is an essential part of Software development.

Why do I need a code review?

  1. Because the second pair of eyes, when looking at the code at his/her own pace, has a good chance of finding a glitch in the code OR preventing me from checking in a bad code.


Remember, the author trusts your judgment and is therefore asking you for your precious time to provide constructive feedback on his/her code.

When we are narrowly focussed on the implementation of a particular interface, or a processor class, we are likely to make mistakes. To avoid those mistakes from going into production, and providing a bad customer experience, we ask our peers to review our work.

When reviewing anyone’s code, at the least, I look for:

  1. Team’s or company’s coding guidelines being followed
  2. Indentation.
  3. Long method code smells.
  4. Repetitions of any logic.
  5. Nested if loops, for loops, switch statements.
  6. Null checks, empty checks, date validations correct.
  7. Enough instrumentation and exception/error handling.
  8. Unit tests covering the scenarios.
  9. A lot of comments. This is dangerous if you need to explain your code in english. Comments bring complacency in writing clean code.

Sometimes, it is just better to get 1:1 with the code author to review the code. (sometimes, not always !! )

How to put comments:

  1. Make suggestions, and offer your rationale on why you think one way is better than the other.
  2. Compliment a well-written code.
  3. Ask questions if you are curious about a particular code piece, and label it as a question.

Note: These are basic for folks who are just starting and are in their early years of career. As people get more domain knowledge, and as they gain experience, code reviews can get more detailed.

I ideate on things that annoy me, so that those things can be improved.