This document discusses best practices for code reviews. It provides guidelines for conducting effective code reviews, including reviewing no more than 400 lines of code at a time and taking 60-90 minutes for reviews. It also lists fundamentals to check like warnings, unused code, and naming conventions. Popular code review tools are mentioned. Conducting code reviews can improve code quality, catch bugs earlier, share knowledge, and mentor junior developers.

1. Code Review (CR)
Improve code quality, reduce bugs and make sure clean code.
R M Shahidul Islam Shahed

3. 01. Build and Test — Before Code
Reviews

4. 02. Check No More Than 400 Lines at a
Time

5. 03. Take enough time for a proper,
slow review,
but not more than 60–90 minutes

6. 04. Give Feedback That Helps (Not Hurts)

7. 05. Use checklists,
Set goals and capture metrics

8. 06. Verify that the defects are actually
fixed

9. 07. Use lightweight,
tool-assisted code reviews

10. 08. Review the right things,
let tools to do the rest

11. 09. Everyone should code review

12. Code Review Checklist -
Fundamental

13. Checklist
1. Make sure that there shouldn't be any project warnings.
2. It will be much better if Code Analysis is performed on a project (with all Microsoft
Rules enabled) and then remove the warnings.
3. All unused usings need to be removed. Code cleanup for unnecessary code is
always a good practice.
4. 'null' check needs to be performed wherever applicable to avoid the Null
Reference Exception at runtime.
5. Naming conventions to be followed always. Generally for variables/parameters,
follow Camel casing and for method names and class names, follow Pascal casing.
6. Make sure that you are aware of SOLID principles.
7. Code Reusability
8. Code Consistency
9. Code Readability
10. Disposing of Unmanaged Resources

14. Checklist
11. Proper implementation of Exception Handling
12. Making sure that methods have less number of lines of code.
13. Peer code reviews.
14. The code is unit testable
15. Logging used appropriately (proper logging level and details)
16. Avoid nested for/foreach loops
17. Use anonymous types if code is going to be used only once.
18. Try using LINQ queries and Lambda expressions to improve Readability.
19. Use access specifiers
20. Use interfaces wherever needed to maintain decoupling.
21. Mark a class as sealed or static or abstract as per its usage and your need.

15. Reasons Why Code Reviews
1. Double-Check if Requirements Are Fulfilled
2. Fewer Bugs in the Code
3. Improved Code Readability
4. Knowledge-Sharing
5. Style of Code Becomes Similar
6. Removes the Single-Point of Failure
7. Better Estimates and Better Planning
8. Improves Code Quality by Peer Pressure
9. The Cost of Defects Is Lower the Earlier They Are Detected
10.Mentoring Junior Developers

16. Some Popular Code Review Tools
1. Best Code Review Tools in the Market
2. Collaborator
3. Review Assistant
4. Codebrag
5. Gerrit
6. Codestriker
7. Rhodecode
8. Phabricator
9. Crucible
10.Veracode
11.Review Board

17. Reference:
1. https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs/
2. https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/index.html
3. https://github.com/palantir/gradle-baseline/blob/develop/docs/best-practices/code-reviews/readme.md
4. https://medium.freecodecamp.org/code-review-the-ultimate-guide-aa45c358bbf5
5. https://www.c-sharpcorner.com/article/best-practices-for-code-review/
6. https://simpleprogrammer.com/why-code-reviews-make-better-code-teams/
7. Clean Code: A Handbook of Agile Software Craftsmanship
8. https://www.codeproject.com/Articles/1156196/Code-Review-Checklist
9. https://www.codeproject.com/Reference/593751/Code-Review-Checklist-and-Guidelines-for-Csharp-De