Code review is systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software. The code review process not only improves the software quality but also helps software developers to enhance their skills continuously.
There are many different areas where reviewer can review the code. We've derived high level of checklist points which can help reviewer to review the code.
1. Naming convention (variable, class, methods, constant, Boolean)
2. Less use of hard coding
3. Use of framework feature
4. Indentation
5. History / comments
6. Less use of loops
7. Modularity 8.Readability
9. Reusability
10. Open/Closed Principle
11. Cyclomatic complexity
12. Separation of concerns (SoC)
13. Extensibility / Scalability
14. Usability
15. UI TDD
16. Functional TDD
17. Memory utilisation
18. Global variables
19. Error handling
20. Security
21. Database Standards
22. App performance
23. Thread Safety
24. Corner Cases handling
25. Testability
26. Debug ability
27. Configurability
28. Size of Classes
29. Size of Code
You can checkout more details here.
Reviewing code is not that simple & straight-forward task. Code review needs lot of patience & proper process in order to avoid conflicts. We have derived simple tips & tricks which can be helpful to code reviewers.
Code Review Guidelines:
1. Highlight issues in the code: Here’s an interesting quote on this point: “If an egg is broken by outside force, life ends. If broken by inside force, life begins. Great things always begin from inside.” – Jim Kwik, Learning Expert.
2. Explain relevant principles: If software developers hesitate to accept given suggestions/recommendations, then explain them relevant principles such as Separation of Concerns, SRS (Single Responsibility Principle), Open-Closed principle, Cyclomatic complexity.
3. Discuss relevant quotes: “Any stupid can write the program that computer understands but only good programmers write code that humans understand” – Martin Fowler
4. Do few things offline: Instead of explaining the entire solution to developers during the code review process, simply share the links of relevant websites or encourage them to research on the internet by providing keywords.
5. Consider as an Opportunity to learn best practices: Sometimes software developers may take the code reviewer’s comments personally and defend the code without a valid reason. It then becomes the responsibility of a code reviewer to inform the developer to consider this exercise as an opportunity to learn/discuss best practices, but not to identify issues to criticise.
6. Always be patient and relook if required: Sometimes, developers do not accept suggestions/recommendation and keep debating. A code reviewer many not know the exact context and challenges, when the code was written. A code reviewer should understand all the points being made by the developer without losing patience. Furthermore, to make the point crystal clear, a code reviewer can explain the points on a paper or on a whiteboard by comparing the developer’s approach vs code reviewer’s approach. Every approach has its pros and cons, need to choose the right approach, whichever weighs more after careful evaluation.
7. Explain the need for best coding practices: Generally, software developers mention that best coding practices are not followed due to tight project schedules. Developers may feel that it is an acceptable practice. However, code reviewers should educate software developers that as the code size increases or after sometime, the application becomes very difficult to maintain. Moreover, if a client verifies the code then poor quality code may give wrong impression on the team’s/organisation’s quality standards. It may also impact awarding new projects or referring an organisation to prospective clients.
8. Consult second level code reviewer (if not convinced): If a code reviewer recommends few suggestions, but the developer hesitates to accept these, then discuss it out with the developer. It is quite possible that the code reviewer may not know the entire context. If the developer is still not convinced with the recommendations of the code reviewer, it is perfectly all right to consult a second level code reviewer. However, the developer should ensure that second code reviewer’s suggestions are forwarded to the first code reviewer to ensure that everyone is on the same page.
9. Capture the enhancements and technical debt: It is quite likely that some code review suggestions cannot be implemented during current release. However, a code reviewer should ensure that all accepted recommendations are clearly documented in a shared code review document, so that these are implemented at an appropriate time in future.
10. Document all code review comments: Document all code review comments in an email, word document, excel, or any standard tool used by the organisation. Making a mistake for the first time is acceptable, but it is not a good sign to repeat the same mistake. The code review document helps software developers to cross check the highlighted issues and avoid making similar mistakes in future. Additionally, maintaining a code review document is a mandatory part of the Capability Maturity Model Integration (CMMI) level process.
Code Review Tips:
1. Review fewer than 400 lines of code at a time
2. Take your time. Inspection rates should under 500 LOC per hour
3. Do not review for more than 60 minutes at a time
4. Set goals and capture metrics
5. Authors should annotate source code before the review
6. Use checklists
7. Establish a process for fixing defects found
8. Foster a positive code review culture
9. Embrace the subconscious implications of peer review
10. Practice lightweight code reviews
Tools for Code Reviews
The first step while assessing the code quality of the entire project is through a static code analysis tool. Use the tools (based on technology) such as SonarQube, NDepend, FxCop, TFS code analysis rules. There is a myth that static code analysis tools are only for managers.
Use plug-ins such as Resharper, which suggests the best practices in Visual studio.
To track the code review comments use the tools like Crucible, Bitbucket and TFS code review process.
Conclusion
The above code review checklist is not exhaustive, but provides a direction to the code reviewer to conduct effective code reviews and deliver good quality code. Initially, it would take some time to review the code from various aspects. After a bit of practice, code reviewers can perform effective code reviews, without much effort and time. If you would like to become an expert code reviewer, this code review checklist serves as a great starting point. Happy Code Reviewing!