Quite a number of reVeiw users have asked why Structure101 does not include all those complexity metrics that used to be in reView. These included the CK object-oriented metrics among others. The answer is quite simple –
- Other than a few die-hard metrics nuts, most developers found the sheer volume of numbers more baffling than useful. This was ok for the feature-rich reView product – some users used only the metrics, some never used them. But this was inconsistent with the goals of Structure101 – an easy-to-use tool focussed on software structure.
- We (and others) found that the complexity metrics track each other to a significant degree. If you monitor one you’re more or less monitoring them all! This makes sense – if I have a class with a high Weighted Method Count (WMC) then it wouldn’t be unusual for it to have a high value for Response-for-a-Class (RFC) or Coupling between Objects (CBO).
Having worked with the various “industry standard” metrics at each level in the code (method, class, package, component, …), we came up with the concept of Fat – too much complexity at any one level of design breakeout. Just as Cyclomatic Complexity (CC) (number of possible paths) is a better indicator of complexity at the code level than, say, Lines of Code, we found that dependency graph complexity is a more realistic measure of complexity at higher levels. That is, the number of sub-components is not as useful a measure of complexity as the number of relationships between them.
Simply put, a software structure without excessive structural complexity (XS) is one where every item is decomposed into sub items (e.g. package into classes) in such a way that the dependency graph of the sub items forms an easily-understood “mind-sized-chunk” piece of “design”. We extend the principle to the code by using the CC metric (actually, also graph-based). Finally we detect and measure cyclic dependencies (Tangles), a particularly undesirable structural trait at the package and higher levels.
The result is a simple framework to control 80% of the complexity debt in a code-base for 20% of the effort. Get and keep your XS close to 0 and your code and projects will be a hell of a lot more agile.