Preparing for Java and Spring Boot Interview?

Join my Newsletter, its FREE

Saturday, August 7, 2021

Code Review Checklist and Best practices in Java

What to review while doing Code review
Code Review and Unit testing are some of the best development practices I always recommend, strive for, and enforce as much as possible. Even just by doing code review and Junit test case always offer positive results it can be improved a lot by constantly learning from our mistakes, others mistakes and by observing how others are doing it. I always try to get my code review done by someone with more technical and domain experience so that I can capture any domain-specific scenarios which have been missed during think through the process.

I also try to get my code reviewed with someone with less experience so that I can improve the code readability, have a four-eye check and most importantly I found that when I explain my code to someone as part of code review I myself discover many things which can be improved or left out. 

Overall it always adds something and improves code quality and reduces bugs.

I also review someone else code and voluntarily take part to improve my code understanding ability and offer help to others, In this article, I will list things that I look at while doing code review. 

These are the things that I have been accumulated over the years but I also look forward to you guys contributing your experience, best practices for code review, and suggest how you guys do code review. These tips are independent of language and equally, apply to Java, ASP .NET, or C++ code.

10 points checklist on Code Review

Here are some important points you can keep in mind while doing a code review for your team. This is not a formal checklist but something which I have created from my own experience. If you have anything to add, feel free to do so. 

1) Functional Requirement

code review checklist, code review best practicesDoes Code meet the functional requirement: first and foremost does code meets all requirements which it should meet, point out if anything has been left out.

2) Side effect on existing code

Is there any Side effect of this change: Sometimes one change in your system may cause a bug in other upstream and downstream systems and it’s quite possible that a new developer or anyone who is writing code might not be available on that dependency? This is often directly related to experience in the project and I found that the more you know about the system and its environment better you are able to figure this out.

3) Concurrency

Does the code is thread-safe? Does it have properly synchronized if using the shared resources? Does it free of any kind of deadlock or live-lock? Concurrency bugs are hard to detect and often surfaces in production. Code review is one place where you can detect this by carefully understand design and its implementation.

4) Readability and maintenance

Does the code is readable? Or is it too complicated for someone completely new? Always give value to readability as code is not just for this time it will remain there for a long time and you need to read it many times.

Another important aspect is maintenance as most of the software spends 90% time on maintenance and only 10% time on development it should be maintainable and flexible in the first place. 

You can verify whether the code is configurable or not, look for any hard coding, find out what is going to be changed in the near future, etc.

5) Consistency

This is part of point 4 but I have made it another separate point because of its importance. This is the best thing you can have in your code which automatically achieves readability. 

Since many developer and programmer take part in project and they have there own style of coding, it’s in best interest of everybody to form a coding standard and follow it in letter and spirit. 

For example it’s not good someone using function initialize() and other is using init() for same kind of operation, keep you code consistent and it will look better, read better.

6) Performance

Another important aspect most important if you are writing high volume low latency electronic trading platform for high-frequency trading which strives for micro second latency. Carefully monitor which code is going to execute at start-up and which is going to be executed in a loop or multiple times optimize the code which is going to execute more often.

7) Error and Exception handling

Ask does code handles bad input and exception? It should and that too with predefined and standard way which must be available and documented for support purpose. I put this point well above on my chart while doing a review because failing on this point can lead to your application crash and not able to recover from a fault on other systems or another part of the same application.

8) Simplicity

Always see if there is any simple and elegant alternative available at-least give a thought and try. Many times first solution comes in mind is not the best solution so giving another thought is just worth it.

9) Reuse of existing code

See if the functionality can be achieved by using existing code, the advantage of doing this is that you are using tried and tested code which reduces your QA time and also gives you more confidence. Introducing new libraries introduce a new dependency. I prefer not to try anything fancy until it’s absolutely necessary.

10) Unit tests

Check whether enough JUnit test cases have been written and cover a sufficient percentage of new code. never let you pass the code without the Junit test because the developer often makes an excuse of time but believe me its worth writing it.

Not last but least that put a comment on your java file that by whom it has been reviewed, what issue finds are out and status of those. This will make the whole process official and ensures that due diligence would be applied during code review. It's also good to maintain your own code review checklist or a project wise code review checklist and use it every time while doing a review. There are so many best practices but I have only included those which I follow and found interesting but as I had said earlier this is the area which always needs improvement and nobody is perfect on that. So please contribute your ideas to code review and effective development.


Some older post you may like


Javin @ String split Java said...

Thanks for your comment itoctopus, I agree Concurrency issues are more subtle and most of the time only shows in production due to high volume and different real world, one way to deal with this is load testing which reveals some concurrency issues.

Anonymous said...

I am big fan of Code reviews and spend more time convincing people to do Code reviews than actually doing them :). While I am here, I would like to share couple of benefits of Code review, which I have personally seen.

1) Code review can be a real team building exercise, It increase and improves communication between team members. Though Code review must be given only keeping positives in mind, instead of criticizing other developer.

2) Code review also increase knowledge sharing between team, which means, whole team remains in same page and ready to backup each other. This can be a huge plus for Manager, who needs to manage leaves and resources.

3) Ultimately benefit of Code review is better code quality, reduce testing time and less number of bugs. There is no substitute of Code review.

Now What can go wrong with Code review:

Like anything else Code review also has two sides of Coin, if not done properly it can harm the team. feedback must always be constructive, It's responsibility of Senior develop to educate team and encourage them learn and think through. Code reviewer should never think that he has to find flaws, he can also appreciate fellow developer. Keeping things simple and normal is key to success.

Tom Henricksen said...

Along the lines of "Readability and maintenance" I would include clean code changes like suggested by Robert C Martin in his book, "Clean Code". These are all good tips to keep in mind when we do a code review.

Roman Ivanov said...

It is good to mention about tools that help to automate codereview: checkstyle , pmd, findbug, sonar.

Unknown said...

if concern then security

Dibyendu said...

Majority of times the code reviews are made without a proper explanation what could go wrong and which will not help peer developers to write better and quality code. I start with java docs provided in the code and think if any other developer can really understand it without knowing the end to feature of the API.

Post a Comment