In this article we are going to discuss in a little detail about FxCop rules. There are 200+ rules, so we will touch on the high level important rules.
Why FXCOP is Easy to Use
Among many things, FxCop makes sure you avoid the already known bad coding practices. It is very effective in a multi developer software coding ecology.
FxCop provides you with the flexibility to create your own custom rules, thus extending existing rules to fit the guidelines of a company or client is a feasible option here.
The report generating system is exceptional and provides you with the Analysis reports in an xml format.
Let us look at the high level areas on which FxCop analysis mostly focuses:
Takes care of the design related rules, forcing to adhere to the .net framework design guidelines. Makes sure generic types are used properly, not too many parameters are passed, exposure of generic lists etc. A detail of all the rules under this section can be found in this MSDN link.
This area takes care that the code can work with world-ready libraries and applications. String comparison or date conversion etc., are typical examples where you need to adhere to these guidelines to make sure the code takes care of local culture settings.
This is very important in terms of future maintenance and cost reduction. It specifically takes care of type names, type hierarchy levels, reduce excessive complexity etc. so that code is humanly manageable.
This is a very important aspect, which often goes unnoticed in coding and peer reviews. Testing performance may be cost effective and time consuming. So basic sanity while coding with respect to performance is a must for developers. The rules in FxCop related to performance makes sure you remove unused parameters, unnecessary casting check, avoid uncalled private code, and mark members as static whenever necessary etc.
Reusability focuses on proper thread usage and memory allocation. The rules around this checks object scopes and their disposal, locking objects with weak identity etc.
This is one of the most important aspects of a software. You need to ensure your code is not vulnerable to – at the bare minimum – known threats. The rules around security in FxCop checks SQL queries for any vulnerability, checks for read only array fields, checks for visible pointers, if secured types expose fields etc.
This may sound very trivial but actually, this is one of the most important aspects of coding. You always have to keep in mind readability of code in future by human who is going to maintain, enhance or reuse the code. So the rules under this section makes sure we adhere to the naming conventions as per .NET framework design guidelines.
Take Your Time
There are many more rules under FxCop, which every developer is advised to review gradually. MSDN is a very good source about the details. FxCop rules have evolved over a long period of time, and it will continue to evolve as software coding techniques change. This is a vast topic and should be absorbed by a developer slowly.
Shortcomings so far
None of these are very important and can be ignored in normal scenarios, but it’s worth pointing out.
- Runs only on compiled dll
- Cannot fix any violation
- No provision for customizing the generated reports
Finally, add FxCop to your Visual Studio, write your code and verify against FxCop. Read all the warnings in detail to understand the root cause and how the suggested fix will help in the long run. Try to make it a habit thus improving your coding hygiene.