As developers we usually code for ourselves. What I mean by this, is that we are usually our own audience. We create objects, components and libraries that we use ourselves. We know the ins and outs of our code and because of this we hardly do any defensive coding. Think about code that you inherited throughout your career…
Since I started to publish my code on Nuget , I thought it was time to truly start coding for others. I decided to start using Code Analysis, which is available in Visual Studio Premium or Visual Studio Ultimate.
Code analysis for managed code analyzes managed assemblies and reports information about the assemblies, such as violations of the programming and design rules set forth in the Microsoft .NET Framework Design Guidelines.
My first reaction was that many of the code issues that were found, were quite restrictive. Then I took a step back and thought about why these rules are included in the rule sets. This is when I realized that they are there to help us write maintainable code. If you are using ReSharper, your code will probably satisfy the majority of rules defined in the Basic Correctness Rules rule set for managed code.
Once I fixed all the code issues that were raised based on the Basic Correctness Rules rule set for managed code, I decided to step it up and run the Basic Design Guideline Rules rule set for managed code. At this point some of the issues seemed a bit odd. For example, why would Microsoft recommend that I should not use optional parameters in method signatures? Then it came to me, method signatures that contain optional parameters are difficult to modify down the road.
Using the Extended Design Guidelines Rules rule set for managed code, I came to the conclusion that these rules also force us to ask ourselves architectural questions. They guide us towards code that will be easier to work with in the future.
If you publish open source code, or any code at all, I strongly recommend using Code Analysis. You owe it to yourself and to your peers, to write code that is maintainable.Writing maintainable code will reduce the technical debt left behind as your legacy to developers who will inherit your work. It will also drastically reduce the risks of total rewrites. If your code needs to be rewritten because it’s not understood by anyone, you will have failed to communicate your intent. Remember writing code for a computer is easy, but writing code that can be understood by others is hard.
Common causes of technical debt include (a combination of):
- Business pressures, where the business considers getting something released sooner before all of the necessary changes are complete, builds up technical debt comprising those uncompleted changes
- Lack of process or understanding, where businesses are blind to the concept of technical debt, and make decisions without considering the implications
- Lack of building loosely coupled components, where functions are hard-coded; when business needs change, the software is inflexible.
- Lack of test suite, which encourages quick and less risky band-aids to fix bugs.
- Lack of documentation, where code is created without necessary supporting documentation. That work to create the supporting documentation represents a debt that must be paid.
- Lack of collaboration, where knowledge isn’t shared around the organization and business efficiency suffers.
- Parallel Development at the same time on two or more branches can cause the build up of technical debt because of the work that will eventually be required to merge the changes into a single source base. The more changes that are done in isolation, the more debt that is piled up.
- Delayed Refactoring. As the requirements for a project evolve, it may become clear that parts of the code have gotten unwieldy and must be refactored in order to support future requirements. The longer that refactoring is delayed, and the more code is written to use the current form, the more debt that piles up that must be paid at the time the refactoring is finally done.
The following table lists the rule sets that you can use in Visual Studio Premium or Visual Studio Ultimate:
This rule set contains all rules. Running this rule set may result in a large number of warnings being reported. Use this rule set to get a comprehensive picture of all issues in your code. This can help you decide which of the more focused rule sets are most appropriate to run for your projects. |
|
These rules focus on logic errors and common mistakes made in the usage of framework APIs. Include this rule set to expand on the list of warnings reported by the minimum recommended rules. |
|
These rules focus on enforcing best practices to make your code easy to understand and use. Include this rule set if your project includes library code or if you want to enforce best practices for easily maintainable code. |
|
These rules expand on the basic correctness rules to maximize the logic and framework usage errors that are reported. Extra emphasis is placed on specific scenarios such as COM interop and mobile applications. Consider including this rule set if one of these scenarios applies to your project or to find additional problems in your project. |
|
These rules expand on the basic design guideline rules to maximize the usability and maintainability issues that are reported. Extra emphasis is placed on naming guidelines. Consider including this rule set if your project includes library code or if you want to enforce the highest standards for writing maintainable code. |
|
These rules focus on problems that prevent data in your application from displaying correctly when used in different languages, locales, and cultures. Include this rule set if your application is localized or globalized. |
|
These rules focus on the most critical problems in your code for which Code Analysis is the most accurate. These rules are small in number and they are intended only to run in limited Visual Studio editions. Use MinimumRecommendedRules.rule set with other Visual Studio editions. |
|
These rules focus on the most critical problems in your code, including potential security holes, application crashes, and other important logic and design errors. You should include this rule set in any custom rule set you create for your projects. |
|
These rules focus on the most critical problems in your C++ projects that support the Common Language Runtime, including potential security holes and application crashes. You should include this rule set in any custom rule set you create for your C++ projects that support the Common Language Runtime. |
|
These rules focus on the most common and critical problems in your C++ projects that support the Common Language Runtime, including potential security holes, application crashes, and other important logic and design errors. You should include this rule set in any custom rule set you create for your C++ projects that support the Common Language Runtime. This rule set is designed to be configured with the Visual Studio Professional edition and higher. |
|
These rules focus on the most critical problems in your native code, including potential security holes and application crashes. You should include this rule set in any custom rule set you create for your native projects. |
|
These rules focus on the most critical and common problems in your native code, including potential security holes and application crashes. You should include this rule set in any custom rule set you create for your native projects. This rule set is designed to work with Visual Studio Professional edition and higher. |
|
This rule set contains all Microsoft security rules. Include this rule set to maximize the number of potential security issues that are reported. |
My code is available through NuGet the Brisebois.WindowsAzure Package.
The sources are available on GitHub project Brisebois.WindowsAzure.To install Brisebois.WindowsAzure, run the following command in the Package Manager Console
PM> Install-Package Brisebois.WindowsAzure
I think the trick is to choose the correct rule set – I see people writing line-of-business applications with globalization rules turned on, which is just a waste of time and money. Also code analysis is annoying in that it lacks context – sometimes you’re working on trying to solve a bug by adding a method locally that does something pathological – you’re never going to check that code in, but code analysis still complains about spacing around curly braces and things of that nature.
LikeLike
FxCop allows you to run these rules on your code regardless of VS version. FxCop was around before code analysis was baked into VS and is probably the best way to run this analysis on a build server where you do not have Visual Studio installed.
LikeLike