As information measurements, code metrics give us a useful view of the codebase. Code Metrics based vocabulary makes the code quality a team activity. There are several object-oriented metrics to measure abstraction, instability, method complexity, cohesion, and coupling.
Some of the useful metrics are:
- Associations between types
- Depth of Inheritance Tree
- Cyclomatic Complexity
- Lack of Cohesion of Methods
- Relative Cohesion
- Efferent Coupling
- Afferent Coupling
- Instability
- Abstractness
- Distance from the main sequence
- Inheritance Depth
A tool makes it easier to include metrics into everyday programming activities. NDepend does a good of job providing the metrics at various levels.
Here is a metrics placemat for your reference.
With this tool, you can write metrics based code rules. Its status circle, in the IDE status bar, will turn red when a metric crosses the threshold giving you a shorter feedback. You can turn these code rules into critical rules to fail the build whenever the metrics cross the thresholds. For example, you could write a code rule to fail the build when LOC of any method crosses a threshold value of twenty.
Don’t use the metrics to measure the performance
These are just information metrics.
”A metric is not a God; It is merely a measurement against an arbitrary method. These metrics measure the conformance of a design to a pattern of dependency and abstraction.”, - Bob Martin writes his book Agile Principles, Patterns, and Practices.
The team needs to resist the urge to use these numbers to measure the individual performance. If you let that happen, you will get suboptimal results as there is an old saying “you get what you measure”.
Of all, the sprint velocity and the code coverage are most often misused.
High code coverage without the quality creates a false sense of security.
Issues with the limits
Setting limits on some metrics is hard.
Lower thresholds come in your way
Goal of the incremental design is to do good enough design. YAGNI is a useful idea the experienced designers use in scoping the design activities. You wait for the next story to pull the design. Sometimes you pragmatically take a strategic decision in delaying the refactorings by taking technical debt. Your design is good enough until next story, which may confirm your design or invalidate causing refactorings. Lower thresholds come in the way of strategic and tactical tradeoffs, and force the team to adhere blindly to the metric limits.
As teams have mixed skill sets, they need to account this and allow continuous learning. Lower value limits create a rush environment making it hard to learn and practice to gain the experience.
When a team has yet to gain the expertise, metrics usually cross the lower value limits, causing the build failures if you set up the CI build with checks on metrics. Under the pressure, teams make it green by either increasing the limits arbitrarily, or suspending the check temporarily, or removing it entirely.
Higher thresholds pile up bad code
As we have seen how lower values cause problems, higher thresholds cause different ones. Due to frequent CI build failures, and other reasons, teams use higher thresholds. One problem is that people take them as acceptable limits piling up bad code.
The machine(CI build) alone can't pull the code quality.
Use limits in the code transformation activities
Higher thresholds for CI builds can stop before code becomes crappy.
Shared vocabulary makes the metrics alive. So use them in everyday programming activities and conversations.
The continuous learning lowers the thresholds step by step.
You can target the learning using “from now onwards” goals. The code metrics make them S.M.A.R.T goals.
You can use NDepend to create the goals by creating a baseline. Such shorter feedback help programmers as they write the code.
Use Trends
Trends limits the information metrics to what they are intended. You can use them in your team retrospectives.
NDepend builds the trends(as shown below) automatically from the analysis. You can create your own trend charts.
Here are few more metrics:
- Parameter Count
- Class Instance size
- Method LOC
- Class LOC
- ABT of the Class
Wrap-up
Object-oriented metrics are information metrics that give a useful view. These can’t be tied to the individual performance.
You can use the code metrics:
- As information metrics. Tools such as NDepend help the developers in getting the metrics quickly.
- As part of the team vocabulary in everyday programming activities.
- To find potential refactorings.
- To stop the crappiest code check-ins using high thresholds.
- To create S.M.A.R.T ”from now onwards” goals to drive continuous learning and practice to gain the expertise.