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?
Pingback: Reflective Perspective - Chris Alcock » The Morning Brew #495
Pingback: Weekly Links #83 | GrantPalin.com