metrics

This is the home page for the metrics module.

What does it do?

The NetBeans Metrics module is a plug-in for NetBeans which adds object-oriented metrics capabilities. Once installed, a developer may view metrics on a per-class or project basis, and be able to "drill down" to find out how the metric was calculated. Unlike traditional metrics tools which provide sophisticated reporting of lots of different metrics, the metrics module instead focuses on bringing a small number of metrics into the developer's edit/compile loop.

Metrics are not indications of bugs or poor design, but high metric numbers often indicate how complex, fragile, or sensitive to regressions a class may be. Classes or methods with high metric values may be good candidates for refactoring. It is therefore useful for a developer to monitor project metrics and investigate those metrics which seem out of line.

Like a car's dashboard warning lights, the metrics module flags classes and methods which cross various metric thresholds with a yellow (warning) or red (error) light next to their icons in the Explorer. A developer has the choice of refactoring the class or method, or approving the current metric value; in either case, the warning light goes out. The metrics module is therefore useful as a guide during class creation and maintenance to encourage the development of lighter weight classes which are loosely coupled.

What metrics does the module support?

The metrics module currently supports the following metrics:

• WMC, or Weighted Methods in a Class, is defined as the sum of the complexities of all methods in a class. The problem is that no one agrees on the definition of a method's complexity, so many metrics tools just punt and assign one (1) to each method. In this module I use a variant on McCabe's Cyclomatic Complexity metric, so that methods with more code paths are weighted more heavily.

A high WMC metric value may indicate unnecessary complexity, such as a "hairball" class design or a complex method which could use refactoring. It can also indicate a procedural design hiding in an object-oriented wrapper.

• CBO, or Coupling Between Objects, is defined as the sum of the classes referenced by a class and the number of classes which reference a class. Good object-oriented design recommends that classes be as lightly- coupled as possible, so high CBO metrics may indicate poor design. A class which is tightly coupled with other classes is also more sensitive to changes in those classes, increasing the risk of regressions.

• RFC, or Response For Class, is defined as the sum of all external methods called by a class, plus all methods those methods call. A class with a high RFC is also more sensitive to regressions. It can also be more expensive to maintain, because more knowledge of the called libraries is needed to do effective maintenance. An example of this is to compare a javax.swing method call and a java.util call: because Swing is a much more complex API, it can take longer to make a correct change to its client code than a java.util class.

• MPC, or Message Passing Coupling, is defined as the sum of the number of method calls made by all methods in a class. Like RFC and CBO, MPC is a measure of a class' complexity. Classes with high MPC metrics may be doing too much work, and should be split into smaller, more narrowly focused classes.

• DIT, or Depth of Inheritance Tree, is equal to the number of superclasses of a class. Classes with lots of superclasses have their behavior scattered in lots of places, requiring more effort to maintain them. This is the hidden cost of subclassing, often overlooked in OO designs.

• NOC, or Number Of Children, is the number of child classes. Classes with lots of child classes need to be very carefully modified to avoid regressions in those children.

• NT, or Number of Tramps, is the number of parameters in a class' methods which are not referenced by its code. While there may be valid reasons for unreferenced parameters (such as a default implementation in an abstract base class), in general they can add unnecessary complexity both for clients and sustaining engineers. Worse, their lack of use may indicate a potential bug. Methods which don't reference any instance variables may be better implemented as static methods, as this may improve performance on many VMs.

How do I use the module?

Look here for documentation.

How to get the module

The module can be built from sources. Download it, compile it and create the nbm (NetBeans Module) file using " ant nbm". Inside NetBeans open the Update Center and install the metrics.nbm file you just created.

To do items

The following enhancements are currently planned:

• Dynamically load metrics from separate packages (metriclets?), so that developers interested in extending the metrics module do not need to write their own module or create a variant of this one.
• Improve performance; in particular, speed up the look up of method metric approvals.
• Per-project threshold settings (requires the new Project API).
  

The following UI enhancements are also planned (suggestions welcome!):

• Modify the metric labels in the Properties pane to show which ones cross thresholds (bold, perhaps?).
• Add metrics leaf node to methods.
  
• Propogate the warning and error lights up the containment tree to facilitate drill-down.
• Change the metrics leaf node to be a contain with each metric as a separate child.

Want to comment or help?

We are open to your ideas. If you have any questions, suggestions or improvements regarding this module, feel free to use the NetBeans mailing lists .