The primary motivation behind any code review is to improve the overall quality of the code. Code quality is very important. This almost goes without saying, especially if your code is part of a team project or is accessible to others, such as open source developers and customers through escrow agreements.

If every developer was free to code as they pleased, you would end up with the same kind of code written in so many different ways, and ultimately the code would become an unwieldy mess. That is why it is important to have a coding standards policy that outlines the company's coding practices and code review procedures that are to be followed.

When code reviews are carried out, colleagues will review the code of other colleagues. Colleagues will understand that it is only human to make mistakes. They will check the code for mistakes, coding that breaks the company...

The normal procedure for carrying out a code review is to make sure your code compiles and meets the requirements set. It should also pass all unit tests and end-to-end tests. Once you are confident that you are able to compile, test, and run your code successfully, then it is checked in to the current working branch. Once checked in, you will then issue a pull request.

A peer reviewer will then review your code and share comments and feedback. If your code passes the code review, your code review is completed and you can then merge your working branch into the main trunk. Otherwise, the peer review will be rejected, and you will be required to review your work and address the issues raised in the comments provided by your reviewer.

The following diagram shows the peer code review process:

Preparing for a code review can be a right royal pain at times, but it does work for better overall quality of code that is easy to read and maintain. It is definitely a worthwhile practice that teams of developers should carry out as standard coding procedures. This is an important step in the code review process, as perfecting this step can save the reviewer considerable time and energy in performing the review.

Here are some standard points to keep in mind when preparing your code for review:

• Always keep the code review in mind: When beginning any programming, you should have the code review in mind. So keep your code small. If possible, limit your code to one feature.
• Make sure that all your tests pass even if your code builds: If your code builds but you have failing tests, then deal immediately with what's causing those tests to fail. Then, when the tests pass as expected, you can move on. It is important...

When leading code reviews, it is important to have the right peoplepresent. The people who will be in attendance at the peer code review will be agreed upon with the project manager. The programmer(s) responsible for submitting the code for review will be present at the code review unless they work remotely. In the case of remote working, the reviewer will review the code and either accept the pull request, decline the pull request, or send the developer some questions to be answered before taking any further action.

A suitable lead for a code review should possess the following skills and knowledge:

• Be a technical authority: The person leading the code review should be a technical authority that understands the company's coding guidelines and software development methodologies. It is also important that they have a good overall understanding of the software under review.
• Have good...

There are different aspects of the code that have to be considered when reviewing it. Primarily, the code being reviewed should only be the code that was modified by the programmer and submitted for review. That's why you should aim to make small submissions often. Small amounts of code are much easier to review and comment on.

Let's go through different aspects a code reviewer should assess for a complete and thorough review.

Company's coding guidelines and business requirement(s)

All code being reviewed should be checked against the company's coding guidelines and the business requirement(s) the code is addressing. All new code should adhere to the latest coding standards and best practices employed by the company.

There are different types of business requirements. These requirements include those of the business and the user/stakeholder as well as functional and implementation requirements. Regardless...

Code reviews should take place when the development is complete and before the programmer of the code passes the code on to the QA department. Before any code is checked into version control, all the code should build and run without errors, warnings, or information. You can ensure this by doing the following:

• You should run static code analysis on your programs to see whether any issues are raised. If you receive any errors, warnings, or information, then address each point raised. Do not ignore them as they can cause problems further down the line. You can access the Code Analysis configuration dialog on the Code Analysis page of the Visual Studio 2019 Project Properties tab. Right-click on your project and select Properties | Code Analysis.
• You should also make sure that all your tests run successfully, and you should aim to have all your new code to be fully covered by normal and exceptional use cases that test...

It is worth remembering that code reviews are aimed at the overall quality of code in keeping with the company's guidelines. Feedback, therefore, should be constructive and not used as an excuse to put down or embarrass a fellow colleague. Similarly, reviewer feedback should not be taken personally and responses to the reviewer should focus on suitable action and explanation.

The following diagram shows the process of issuing a Pull Request (PR), performing a code review, and either accepting or rejecting the PR:

Providing feedback as a reviewer

Workplace bullying can be a problem, and programming environments are not immune. Nobody likes a cocky programmer who thinks they are big. So, it is important that the reviewer has good soft skills and is very diplomatic. Bear in mind that some people can easily be offended and take things the wrong way. So know who you are dealing with...

In this chapter, we have discussed the importance of performing code reviews and the complete process of getting code ready for review and responding to reviewer comments as the programmer, along with how to lead a code review and what to look for when performing a review as the code reviewer. It can be seen that there are clearly two roles in a peer code review. These are the reviewer and the reviewee. The reviewer is the person performing the code review, and the reviewee is the person whose code is being reviewed.

You have also seen how you, as a reviewer, can categorize your feedback and why soft skills are important when providing feedback to fellow programmers. And as a reviewee whose code is being scrutinized, you have seen how important it is to build upon positive and optional feedback and how important it is to act upon critical feedback.

By now, you should have a good understanding of why it is important to conduct regular code reviews, and why...

1. What are the two roles involved in a peer code review?
2. Who agrees on the people that will be involved in the peer code review?
3. How can you save your reviewer time and effort prior to requesting a peer code review?
4. When reviewing code, what kinds of things must you look out for?
5. What are the three categories of feedback?

• https://docs.microsoft.com/en-us/visualstudio/code-quality/?view=vs-2019: This documentation by Microsoft provides information on the different tools available to help you analyze and improve the quality and maintainability of your code.
• https://en.wikipedia.org/wiki/Code_review: There are many useful links on this page to further your knowledge of code reviews and their value to your business.
• https://springframework.guru/gang-of-four-design-patterns/: Gang-of-Four design patterns book.
• https://www.packtpub.com/application-development/net-design-patterns: .NET Design Patterns, by Praseed Pai and Shine Xavier.
• https://help.github.com/en: GitHub's help page.