Which Code Metrics Do You Consider Important?
Posted by Davy Brion on December 9th, 2009
I’m looking into which Code Metrics we should keep an eye on, or at least pay attention to. Of all the metrics that NDepend offers, i only seem to find the following ones valuable (some only slightly):
- On the Type level:
- The number of lines of code of the type
- Afferent coupling
- Efferent coupling
- Cyclomatic complexity
- Association between classes
- Number of children
- Depth of inheritance tree
- On the Assembly level:
- Efferent coupling
- Relational cohesion
Some metrics that you’d expect to be interesting but that i’m specifically not interested in:
- On the Type level:
- Lack of Cohesion Of Methods: i can’t help but think that this metric is calculated incorrectly. When studying NDepend’s xml output, i noticed quite a few types where the number of instance fields was incorrect (it listed a lot more than there actually were, and it seems to be related to having compiler generated classes when you’re using lambda statements quite heavily). Since the number of fields metric is used to determine the cohesion of the class, this result just doesn’t seem to be correct if the number of fields is incorrect.
- On the Assembly level:
- Afferent Coupling: our client-side and server assemblies share no types, except for the types declared in a common assembly. That common assembly only contains Request/Response types and DTO’s, nothing else. The afferent coupling of the common assembly is always high, though that metric is meaningless for us. The afferent coupling of the client-side and server side assembly is 0 since they never use each other directly. So basically, that metric is useless for us.
- Instability: Instability is the ratio of efferent coupling to total coupling. Since total coupling is the sum of efferent coupling and afferent coupling, it is in our case essentially the same as efferent coupling (because our afferent coupling is 0), which means that the ratio of efferent coupling to total coupling is 1, which is supposed to indicate a completely instable assembly.
- Abstractness: this is the ratio of abstract types (abstract classes and interfaces) to the total number of types. This is also useless for us since a very high percentage of our classes implements an interface, and usage of those classes always happens through the interface type instead of the concrete type
- Distance From Main Sequence: this metric is based on instability and abstractness of an assembly… again, useless in our case.
I might be wrong about the whole thing, but i can’t help but think that these metrics are no longer relevant, or even present an incorrect picture about the quality of the code if you’re making heavy use of practices like Dependency Injection and tools like an Inversion Of Control container.
So i’d like to ask you: which metrics do you consider to be important? Which ones do you ignore? Am i wrong about the ones i’ve listed as not interested in? Are there other metrics that you think i really need to take into account?
December 9th, 2009 at 12:46 pm
The pain level it takes to add new features / modify existing ones is a pretty good metric, although a highly subjective one.
December 9th, 2009 at 2:54 pm
well yeah, but that’s not one that you can easily get out of any tool
December 9th, 2009 at 6:15 pm
A few things I like to keep track of:
- Undocumented public methods
- Code coverage of Unit tests (but being aware that this isn’t an end to anything in itself)
- Number of comments (only zero is a flag – on a purely numbers level this shouldn’t need to be high if good naming used)
December 9th, 2009 at 11:44 pm
I found metrics on method level pretty useful:
NbLinesOfCode, NbILInstructions, Method rank, Afferent coupling at method level (MethodCa), Efferent coupling at method level (MethodCe), Code Source Cyclomatic Complexity, IL Cyclomatic Complexity (ILCC), IL Nesting Depth, NbParameters, NbVariables, NbOverloads, PercentageCoverage, NbLinesOfCodeCovered, NbLinesOfCodeNotCovered, PercentageBranchCoverage
but my preferred measure, is to assess how changed an new code is covered by tests:
Are you sure added and refactored code is covered by tests?
December 10th, 2009 at 6:54 am
@Patrick
that would only be useful of if the code coverage metric was actually useful
any thoughts/comments on what i said about the metrics that i think are irrelevant when using DI/IOC?
December 10th, 2009 at 9:43 am
Concerning coverage;
High Test Coverage Ratio is a good thing, Anyway!
Concerning DI/IOC, basically you say that because you abide by good abstraction principles, metrics values will be good anyway and you don’t need them. The other half is true, if metrics value are bad, it certainly means you don’t abide by good principles and thus, metrics are useful
)
Btw, instability IS a better thing than stability (in the context of abstracness vs. instanbility), since instability means that changes won’t propagate too much.
December 10th, 2009 at 9:47 am
@Patrick
no, i’m saying that:
a) some of the metrics show bad results, even though the code is good and i think it’s solely because of DI/IOC
b) some of the metrics are wrong (i think)… the number of fields reported for a type is often incorrect when lambda’s are used (even though the anonymous classes also show up in the report) which ruins the LOCM metric
December 10th, 2009 at 9:57 am
one more, often forgotten: the size of your wallet
December 10th, 2009 at 10:55 am
[...] Which Code Metrics Do You Consider Important? – Davy Brion discusses the topic of Code Metrics with a look at the various metrics offered by NDepend, classifying them into ones he finds useful, and ones that you might thing would be interesting but he doesn’t find interesting. Some good discussions starting in the comments on this one [...]
December 11th, 2009 at 4:31 pm
http://davybrion.com/blog/2009/12/ndepend-and-lack-of-cohesion-of-methods-not-to-be-trusted/
that’s an example of how incorrect the LOCM and LOCM HS methods can be
December 13th, 2009 at 11:58 pm
[...] Which Code Metrics Do You Consider Important? Good information to collect for any programming project. [...]