It is a human nature to make mistakes, but mistakes in source code can lead to expensive consecutive mistakes if not fixed in time. Unfortunately, black box testing often cannot fully cover software. And even if it does, fixing a bug found by QA is at least two times as expensive as fixing it before issuing a build. Performance bottlenecks, security, scalability and reliability issues should be identified as early as possible. This is where code review comes in.

Code review, which is also known sometimes as peer review, is a set of systematic examination measures used to critique computer code with the objective of finding and fixing bugs early in the development stage in order to develop high quality software and perfect skills of developers for future projects.

Carrying out regular code reviews has the advantages of saving money and time, having to fix fewer errors per line of code, using highly decreased development resources while increasing productivity and enjoying software that is 90 percent defect free.

Being aware of best practices for .NET code review is necessary to make the software development process as efficient as possible and deliver quality products in time and on budget. Even though it is impossible to enumerate all of the best practices here, we have included those that are absolutely indispensable. So here are top five best practices for .NET code review:

1. Present project implementation ideas to developers prior to development. It is important for developers to understand how to do the task if the solution is ready-made, or know where to look for such a solution if finding it is part of the task. In the latter case, the process of communication between developers and technical leads becomes vital for the final decision to be the most efficient.

2. Create and follow a code review checklist. This checklist should help enumerate and analyze the specific aspects of what reviewers should pay attention to in order to make the code reviewing process as efficient as possible. Obviously, each project is different and will have its own specifications when it comes to the checklist, but as a general rule, it should ideally follow the outline of coding standards documents. When drafting a checklist, each developer should also examine their strengths and weaknesses and pay extra attention to the areas where they can be more vulnerable. Following is a sample code review checklist that covers the main areas necessary for review:

a) Does the code work as expected? The assumption is that the code works, but often it turns out that the code does not work as the customer would expect.

b)  Are there any warnings generated by a static code analysis tool? Such tools can check for a lot of guidelines enforcements, and their reports should not be missed.

c) Are comments correct? Comments should be correct and not outdated. Otherwise, they will confuse team members. At the same time, comments should be meaningful and present only where absolutely needed.

d) Are there necessary checks for null values? If a variable or input parameter is not supposed to be null, the null check should throw an exception. Otherwise, there should be an alternative if-statement for the null value.

e) Are there necessary checks for invalid values in enumerables? If there is a switch or an if-statement checking enumerable string values or an enum, default or else operator most often should always consider the invalid values, not the other non-mentioned, valid ones.

f) Are custom exceptions correctly declared? Each custom exception should be inherited from the ApplicationException class and should implement at least two constructors: with string and (string, Exception) parameters. If throwing an exception with an empty message is allowed, two more constructors should be implemented: () and (Exception).

g) Are exceptions correctly handled? Generic exceptions should never be suppressed (at least without logging). However, if exceptions are logged, duplicate logging should be avoided as well.

h) If code may be called by multiple threads, is it thread safe? Checking for thread safety is vital, because such errors are hard to track down, and it is easier to avoid them early rather than fix them later.

i) Is the code secure? Security issues can hardly be covered by QA or unit tests, but they are certainly important. For example, if there is a method that is supposed to be called by administrators only, it is better to restrict the method itself, even if the respective action is available only to administrators in the user interface.

j) Are unmanaged or IO resources correctly disposed of? Resources that are not disposed of can cause unexpected crashes or memory leaks. Each such resource should be disposed of correctly after using.

k) Are the most effective algorithms used? Common mistakes include:

• Using IList instead of IDictionary or Hashtable leads to unnecessary O(n²) complexity instead of O(n).
• Using multiple consecutive string concatenations instead of StringBuilder or String. The format increases complexity as well as memory usage.
• Unnecessary web service calls can slow down the application considerably.

l) Are string comparisons correct? Using case sensitive comparisons instead of case insensitive ones in some cases (for example, file names comparisons) can cause errors that are hard to detect. Ideally, each string comparison in the code should be reviewed.

m)  Are the classes, methods, properties and variables named correctly? A static code analysis tool will check naming conventions, but often it is possible to come up with better names.

n)  Is unit tests coverage good enough? Unit tests should be reviewed as well. The same checklist as above can be followed.

3. Use automated tools for code review. Automation is essential for code quality, first of all, to eliminate the necessity for routine checks (saving time spent on reviews by skipping descriptions of incorrect formatting and naming), and secondly, for enforcing code guidelines without the reviewer assuming the role of a strict professor worried about every misplaced comma. Automation takes subjective opinions out of the equation and serves as a neutral and impartial force.

The most popular static code analysis tools for .NET are SonarQube and FxCop. They can check for dozens of code guideline enforcements such as:

• Classes, methods and variables naming conventions,
• Empty classes or methods,
• Unnecessary parentheses,
• Correct classes and methods declarations,
• Access modifiers, etc.

4. Hold regular discussions of the main review results. Best development practices and how they can be implemented should be communicated to developers on a regular basis using an example of well-written code (with a focus on successful solutions in particular), rather than targeting specific errors of individual developers (which can negatively influence the atmosphere in the team). Good communication between all project participants (including clients and stakeholders, if necessary, as well as managers and testers) is a vital aspect of being on the same page in terms of code quality. Being patient with team members who don't boast extensive technical backgrounds and speaking their language brings the team closer and ensures better quality of the end product. Team members also learn from each other through a more profound understanding of the code base and can use that knowledge in subsequent projects, as well as project support.

Holding regular meetings and discussions may also have the following benefits:

• Consistency of design and implementation throughout the project,
• A common knowledge database where project data is stored may help bring new team members on board when others become unavailable,
• Walking in the shoes of another team member helps see the product more objectively, and a person looking at a piece of code for the first time may have a fresh perspective,
• Being recognized by peers boosts morale in the team and motivates developers to code better,
• Teams become closer by interacting on a more personal level and working together toward a common goal.

5. Don't take mistakes and problems personally. Even though making mistakes is a natural part of writing code, they are too costly, and are therefore always considered the ‘enemy.' But just like failure is an intrinsic part of success, mistakes are acceptable (and they will happen on every project, with every developer) as long as they don't end up in the product that's already gone into production, costing investors money and developers their reputation.

It may be helpful for developers to remember that the whole objective of code review is to find issues with code. No matter how excellent their product is, code review is not targeted at praising their coding prowess, but at finding loopholes in it. It is best to look at the process this way: finding mistakes improves code; it doesn't critique its creator. Learning from mistakes and sharing that knowledge with others is what developers should be taking out of the whole process.

Another sometimes painful aspect of code review is encountering developers who are more advanced and better skilled. The trick is to not view them as rivals but to learn from them. When conducting regular reviews, it is important to be diplomatic and not forget that praise is critical for all creative professionals (and developers are creatives, no doubt about that), and that criticisms and notes go down better with a bit of recognition of the skills that enabled the developer to write the code in the first place.

Carrying out .NET code review on a regular basis may help keep development quality at the designated level of excellence, develop high quality defect-free software, comply with industry standards and share knowhow between developers. Recognizing and following best practices in .NET code review can enable all parties involved in software product development to bring their efforts to perfection and centralize the latest knowledge in their niche.