Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Monitor .NET Code Quality with FxCop and Custom Rules : Page 2

You no longer have to rely solely on experience and code reviews to find code problems; FxCop can find many problems for you. It even lets you create and enforce custom rules that apply specifically to your organization's code.


advertisement
Some Important FxCop Terminology
A target refers to the managed assembly on which FxCop is used to inspect against compliance to the standards. FxCop represents the checks it performs during an analysis as rules. FxCop rules are implemented as public classes. All rules implement a Check method that returns a reference to an object of the ProblemCollection class from the FxCop SDK. This value determines whether a violation has occurred. A rule consists of managed code that analyzes the target(s) and returns a message stating its findings. These messages not only display standards violations but also provide guidance on how to rectify the violations in the source code.

Rules in FxCop are categorized as Default Rules and Custom Rules. The default rules are grouped based on category. Here are some of the important in-built rules in FxCop, their objectives and an example of each.

  • Design Rules—these are rules about the design of your .NET types and assemblies.
    Example: Abstract types should not have constructors.
  • Globalization Rules—these are rules concerning globalization and localization.
    Example: Do not hardcode locale specific strings.


  • Naming Rules—these are the rules that cover naming conventions.
    Example: Avoid type names in parameters.
  • Performance Rules—these rules check for possible performance improvements or impediments to code.
    Example: Test for empty strings using string length.

  • Security Rules—These are rules that check for secure code.
    Example: Pointers should not be visible.
  • Usage Rules—these are rules that provide guidance about the standard .NET framework usage.
    Example: Finalizers should be protected.

The FxCop Interface
FxCop exposes two interfaces: a GUI-based user interface and a command-line interface. The FxCop GUI has three windows (see Figure 1). A configuration pane displays the targets and rules for the current FxCop project in a TreeView. You use the configuration pane to select the target assembly or assemblies (you can analyze more than one assembly at the same time) and the rules that FxCop will use to analyze the target assembly.

 
Figure 1: The FxCop User Interface: Here's a screenshot of the FxCop UI showing the Configuration Pane, the Message Pane and the Properties Pane.
 
Figure 2: An FxCop Analysis Report: The figure shows a sample FxCop analysis report containing several message types.
A Messages pane displays an analysis report on the target assembly after inspection. These messages are displayed at the following levels based on their importance and criticality.
  • Critical Error
  • Error
  • Warning
  • Critical Warning
  • Information
Figure 2 shows a typical FxCop analysis report.

A Properties tab displays information about the target assembly, including the namespace, type and type members, group of rules, rule, or message. You can select a rule, a group of rules, discard some rules, etc. to build a set of rules against which you want FxCop to test the assembly.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap