FxCop analyzers are a port of the most important Microsoft code analysis rules (CAXXXX), which were implemented as an MSIL-based binary analysis. Compared to the post-build binary analysis, the FxCop analyzers have added advantage of live analysis and diagnostics while editing code, as well as rich code fixes to fix these issues.
FxCop contains rules in various different categories such as performance, security, code style, API design, maintainability, and so on. In the example covered in this section, we focused on the following performance rules:
- CA1801 (Review unused parameters) (https://msdn.microsoft.com/en-us/library/ms182268.aspx): A method signature includes a parameter that is not used in the method body.
- CA1810 (Initialize reference type static fields inline) (https://msdn.microsoft.com/en-us/library/ms182275.aspx): When a type declares an explicit static constructor, the just-in-time (JIT) compiler adds a check to each static method and instance constructor of the type to make sure that the static constructor was previously called. Static constructor checks can decrease performance.
- CA1814 (Prefer jagged arrays over multidimensional) (https://msdn.microsoft.com/en-us/library/ms182277.aspx): A jagged array is an array whose elements are arrays. The arrays that make up the elements can be of different sizes, which can result in less wasted space for some sets of data.
- CA1815 (Override equals and operator equals on value types) (https://msdn.microsoft.com/en-us/library/ms182276.aspx): For value types, the inherited implementation of equals uses the Reflection library and compares the contents of all fields. Reflection is computationally expensive, and comparing every field for equality might be unnecessary. If you expect users to compare or sort instances, or to use instances as hash table keys, your value type should implement equals.
- CA1816 (Call GC.SuppressFinalize correctly) (https://msdn.microsoft.com/en-us/library/ms182269.aspx): A method that is an implementation of Dispose does not call GC.SuppressFinalize, or a method that is not an implementation of Dispose calls GC.SuppressFinalize, or a method calls GC.SuppressFinalize and passes something other than this.
- CA1821 (Remove empty finalizers) (https://msdn.microsoft.com/en-us/library/bb264476.aspx): Whenever you can, avoid finalizers because of the additional performance overhead that is involved in tracking object lifetime. An empty finalizer incurs added overhead without any benefit.
You can read detailed documentation about all the FxCop performance rules at https://msdn.microsoft.com/en-us/library/ms182260(v=vs.140).aspx.
Note that even though majority of Microsoft Code Analysis performance rules have been ported to FxCop analyzers package, not all rules are enabled by default in the NuGet package. You can view and configure the suppression state and severity of each FxCop rule by using the ruleset editor. For further guidance on using the ruleset editor, refer to recipe Using ruleset file and ruleset editor to configure analyzers, in Chapter 2, Consuming Diagnostic Analyzers in .NET Projects.
Note that even though majority of Microsoft Code Analysis performance rules have been ported to FxCop analyzers package, not all rules are enabled by default in the NuGet package. You can view and configure the suppression state and severity of each FxCop rule by using the ruleset editor. For further guidance on using the ruleset editor, refer to recipe Using ruleset file and ruleset editor to configure analyzers, in Chapter 2, Consuming Diagnostic Analyzers in .NET Projects.