Best Practices As Specified By .NET Design Guidelines

.NET Coding Standards

• Variable/Method/Class/Assembly names should be self-explanatory
• Pascal Casing & Camel Casing
• Add concise comments wherever necessary - especially complex logic
• Add XML comments for all methods – including event handlers
• Logical Division of code and modular code is a must
• Class variables/properties should be made public only when required.
• Avoid using Goto or Resume.
• Empty catch blocks and unnecessary exceptions should be avoided.

Code Review

1. Make sure that proper conventions are followed and inefficient code is not written
2. Primary objectives of code review
3. Ensure efficient code
4. Ensure Maintainability
5. Ensure Readability
6. Manual code review is mandatory

Code Analysis/Microsoft All Rules

1. Can consider a filter before manual code review
2. Reduces the effort required in manual code review
3. Analyzes managed code/assemblies for violations of the programming and design rules set in Microsoft .NET Framework Design Guidelines
4. The tool represents the checks as warning messages
5. The Warning messages contain,
   
   
1. The category number. Example: CA1303
2. The issue with the code/design
3. When it is possible
4. Possible solutions to fix the issue.
   
   

Configuring Code Analysis

Go to properties of project.

 

Go to "Code Analysis" tab, select “Microsoft All Rules” as the rule set and "Save & Close".

 

Right click on the project and click on “Run Code Analysis”, or build/rebuild the solution if you have multiple projects.

 

Naming – Additional Tools

Certain business terms cannot be avoided. In order to recognize the terms, add them to a custom dictionary.

Configuring a custom dictionary

• Add an XML file to the solution (not to a particular project).
• Then, add an existing item to each project, add like below.
• This is only for unavoidable business terms – should not be used as a suppression tool!

Common Mistakes

1. Understanding units of code
2. Cyclomatic Complexity
3. Tightly Coupled and Loosely Coupled classes

Naming

1. Avoid Hungarian notations (Example: iCount, sName, sAddress)
2. Avoid naming controls with prefix of type. Example: txtName, lblMessage
3. Always give meaningful variable names! (int i, string s are not accepted)
4. Camel Casing should be used for local variables (example: requestNumber, employeeName).
5. Pascal Casing for Classes & Properties (example: RequestNumber, EmployeeName).
   
   
1. Avoid abbreviations of common terms like Number No. Always use the full word.
2. When using Linq to SQL or entity class, ensure the columns of the stored procedure are compliant with MS All Rules – use Alias names if necessary.
3. If a property contains a URL and it is named so (example: pageURL or siteURL), the type should be System.Uri.
4. Catch Specific Exceptions!
5. For messages to be displayed to user or any other string literals, use a Resource File.

Code Analysis should be a part of development. Resolving CA warnings post development activity will take more time.

Code Review..

• Peer Code Review.
• Provides a different perspective – your colleague may know a better way to accomplish the functionality.
• Some issues in code that may not have been covered in Unit Testing may be spotted in peer review.
• Group Review.
• Group reviews provide the most feedback.
• Provides the opportunity to learn efficient coding from the rest of the team.

Source

MSDN Page for Code Analysis – Managed Code Warnings