Evaluating Code: FxCop

---

You may have noticed that most .NET code from Microsoft follows certain patterns. For example, class names (such as SqlConnection) use Pascal casing, while parameter names (such as connectionString) use camel casing.

Note

Pascal casing capitalizes each concatenated word in an identifier. Camel casing capitalizes all concatenated words except the first, leading to a “camel’s hump” in the middle of two-word identifiers.

While this sort of choice is arbitrary (camel-cased identifiers perform no better or worse than Pascal-cased ones), the .NET Framework developers argue that there’s a benefit to consistency across all class libraries. This consistency in the FCL extends far beyond simple naming guidelines. The .NET Framework General Reference includes an entire section of “Design Guidelines for Class Library Developers” (it’s also available online at http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconnetframeworkdesignguidelines.asp) that covers 13 major areas:

• Naming guidelines

• Class member usage guidelines

• Type usage guidelines

• Guidelines for exposing functionality to COM

• Error raising and handling guidelines

• Array usage guidelines

• Operator overloading usage guidelines

• Guidelines for implementing Equals and the equality operator

• Guidelines for casting types

• Common design patterns

• Security in class libraries

• Threading design guidelines

• Guidelines for asynchronous programming

After you’ve worked with the .NET Framework for a while, you’ll find that you expect class libraries to conform with these guidelines. For example, you’ll expect to be able to invoke just about any method asynchronously, because that’s just how .NET works in general.

Wouldn’t it be nice to be able to check whether a new class library conforms to the design guidelines? The .NET developers think so too, which is why they’ve released a free tool named FxCop (www.gotdotnet.com/team/fxcop/). While FxCop doesn’t check for conformity with every single design guideline, it does incorporate a database of more than 200 rules from the guidelines.

There are two main uses for FxCop. First, you can use it to get a quick feel for whether a class library that you’re contemplating using conforms with the design guidelines. Second, you can use it to check your own code (if you’re writing class libraries) to see whether you’re doing things the .NET way.

FxCop organizes its work into projects. A project consists of one or more assemblies to be checked, and one or more rules to be used to check the assemblies. Figure 7.9 shows FxCop in action, in this case looking at the DownloadEngine.dll assembly with all rules enabled. As you can see, you can select which parts of an assembly to inspect, right down to the member level. Similarly, you can choose whether to enable or disable individual rules, and even to exclude individual warnings.

Figure 7.9: FxCop in action

As you can see, even with the small number of members in DownloadEngine.dll, FxCop found some things to complain about. For more details, you can double-click on any of the rule violations. This will open the Active Message Details dialog box, shown in Figure 7.10.

Figure 7.10: FxCop rule details

If you’re going to use FxCop (or any similar tool, such as Total .NET Analyzer or Compuware DevPartner Studio, both of which I mentioned in Chapter 6, “Pumping Up the IDE”), I have two pieces of advice. First, start using the tool on a regular basis early in your development cycle so that you can correct any problems as they occur. If you wait until you’re ready to release a class library to test for guideline conformance, you’ll probably find hundreds of errors. Then you’ll have to decide between delaying the software’s release or ignoring the tool’s recommendations. Second, use your judgment. There may be good reasons to ignore some or all of the rules in any particular library. Perhaps you’re designing code to wrap a legacy API, for example, in which case you should probably conform to that API’s naming rules rather than the .NET rules. Remember, the design guidelines exist to make life for developers easier, not harder.

RULE

Design guidelines are a means to an end, not an end in themselves.

If you do find yourself trying to automatically fix every single problem that FxCop finds, one quick cure is to run an FxCop analysis of one of the FCL assemblies. Figure 7.11 shows the result of running all of the FxCop rules against System.Data.dll. Obviously the Microsoft designers were not concerned with following every little guideline perfectly.

Figure 7.11: FxCop and the FCL

---