55.1. Code Metrics

Code metrics will serve as a reference to know how maintainable your code is. This feature is new in Visual Studio 2008; in this version it comes with five metrics. All of them have to be looked at with care, and you have to set your own context at the time you evaluate your projects. Figure 55-1 shows the Code Metrics window for a sample project. You open this window from the Analyze Windows Code Metric Results menu. To calculate the metrics you should hit the button on the top-left corner. The Code Metrics window shows a hierarchy of the projects, namespaces, types, and members.

Directly from the list you can filter any of the metrics to show methods that fall within a specified range, export to Excel, configure columns to remove metrics, or create a work item. Export to Excel is particularly useful to generate reports using pivot tables or to work with a flat view of the information using filters and sorts. For example, if you want to look for methods with more than 15 lines of code, filtering directly in the Code Metrics window will get you a lot of namespaces and types, but you will have to expand each to see whether there are any methods, whereas in Excel you can easily filter out namespaces and types and only look at methods.

Work items are activities assigned to someone working on a team project. Team projects and work items are explained in more detail in Chapter 58.

When you see each metric's detail, keep in mind that lower numbers are better for all the metrics except the Maintainability Index.

Figure 55.1. Figure 55-1

55.1.1. Lines of Code

The name is self-explanatory; however, it's worth mentioning that the purpose of this metric should be only to get a clue of the complexity of the code, and must not be used to measure progress. Clearly, a method with five lines of code that calls other methods will be simpler than if you inline all 25 lines of code in that method.

public class OrdersGenerator
{
public void GenerateOrder(Order order)
{
IsUnderCreditLimit(order);
IsCustomerBlocked(order.Customer);
AreProductsInStock(order);
IsCustomerBlocked(order);
SaveOrder(order);
}
// remaining methods are omitted.
}

If you compare a class with six methods as shown in the preceding code with a class having the same functionality, but with all the code inlined in one method, the latter will have 25 lines. Assuming the remaining methods have five lines each, the former will be 30 lines long although it is simpler. You have to be careful about how to consider this metric; a longer class might be better than a short one.

As you saw in Chapter 17, Extract Method refactoring can help you simplify the code.

55.1.2. Depth of Inheritance

This metric counts the base classes; some recommendations are to have a value lower than six. But this, like other metrics, has to be looked at with special care. It's hard to give a recommended value and it's relative to which classes you are inheriting from. If you inherit from LinkLabel, you will have a depth of 4, but your base classes are less likely to change than if you inherit from ProviderXComponent and have a depth of 1. It's more probable that ProviderX will change his component and break yours, while Microsoft will take more care not to break code. But you'll probably never update ProviderX's library. The point is that this metric is relative to what base classes you have.

55.1.3. Class Coupling

This counts the dependencies an item has on other types except for primitives and built-in types like Int32, object, and string. The more dependencies you have, the harder it's supposed to be to maintain, because it would be more probable that changes on other types will cause a break in your code. Similarly to depth of inheritance, the importance you give is relative to the dependencies you have. A class referencing System libraries is less likely to have a break than classes referencing other types on active development. You can see a value for this metric at each level of the hierarchy (project, namespace, type, and member).

55.1.4. Cyclomatic Complexity

The different branches a code may have, caused by such statements as if, do/while, for, and switch will cause your code to increase its cyclomatic complexity.

55.1.5. Maintainability Index

This index is calculated using a formula that considers cyclomatic complexity, lines of code, and the Halstead volume, which is a metric that considers the total and distinct number of operators and operands. It will give you a range between 0 and 100, the higher being the better.

55.1.6. Excluded Code

Code marked with the CompilerGenerated and GeneratedCode attributes won't be considered in the metrics. Datasets and WebServiceProxies are examples of code marked with the GeneratedCode attribute, but other generated code like WindowsForms isn't marked and will be considered in the metric's results.