Maintainability should subsume various properties defining InternalQuality
because the final reason for a software product to hold these properties is the cost of maintenance.
Personally I like the term because when speaking about quality, I always had to distinguish things :
is quality of the product, as the people using the software can define it (grosso modo
is quality of the design, as defined by the technical people making the software.
is high, the customers are happy (nearly tautologic definition). When InternalQuality
is high developers are happy, and keeping the customers happy is less expensive. And so on.
Now I just use "Quality" when speaking about properties the user or customer requires for the software product, and MaintainAbility
for all the internal properties that facilitate the production and maintenance of the software product. --ChristopheThibaut
Are there any metrics for maintainability that can be derived from the code?
And if there are, how much are they subject to Heisenberg problems (e.g. the HeisenbergUncertaintyPrinciple
)? If you measure maintainability metrics, will you get higher metrics, but code that's still as unmaintainable or worse?
lists the following metrics for maintainability:
- Number of parameters passed to each routine
- Number of local variables used by each routine
- Number of routines called by each routine
- Number of decision points in each routine
- Control-flow complexity in each routine
- Lines of code in each routine
- Lines of comments in each routine
- Number of data declarations in each routine
- Number of blank lines in each routine
- Number of gotos in each routine
- Number of input/output statements in each routine
The SEI has published a Maintainability Index Technique for Measuring Program Maintainability: http://www.sei.cmu.edu/str/descriptions/mitmpm.html
It is based on:
Personally, I am very intrigued by the relationship between coupling and maintainability. Many authors have claimed that high cohesion and low coupling is the way to go, yet I believe that a linear relationship between coupling and maintainability just don't seem to make sence. Under such an assumption, less coupling is better. However, everyone will agree that striving for no coupling at all is the ultimate guideline for creating GodClass
-es, which are not exactly ideals w.r.t. maintainability.
Of course, this relationship depends on how you define coupling. I would suggest to consider coupling as the number of collaborations you need to implement a semantically related set of requirements. Under that definition, having no coupling truly leads to GodClass
-es, and having maximum coupling would lead to heavily coupled tool classes which all are responsible for only a very minor detail in the stated set of requirements. This relates to DesignPatterns
in that they propose a degree of collaboration (and therefore coupling) which distributes responsibilities evenly over a number of classes. Maybe DesignPatterns
can be used as the optimal degree of coupling, from which deviations (to both the GodClass
-es and overly distributed responsibilities extremes) would have negative effect on maintainability.
Such a relationship between coupling and maintainability could be visualized as a U-shaped curve in a 2-dimensional space with a Y-axis for maintenance effort and a X-axis for coupling. This model, of course, is totally hypothetical, but seems - at least from my experience - to be more realistic than a linear relationship. -- Bart Du Bois
Many authors have claimed that high cohesion and low coupling is the way to go, yet I believe that a linear relationship between coupling and maintainability just don't seem to make sence.
Your confusion seems to stem from trying to force the maintainability to be a function of only the coupling. What those authors usually mean is that if you hold everything else
constant, lower coupling and higher cohesion reduces maintenance costs. This would mean that the number and size of the classes must remain constant while you change the coupling and cohesion. Pushing the coupling so low that it forces other variables to change (i.e. class size) is outside of their claims.
Another hypothetical model: maintenance_effort = K1 * coupling_metric + K2 * (sum of squares of class sizes) (+ some other factors, which we can ignore for now). This explains your visualized U-shaped curve and maintains the linear relationship between coupling and maintenance.
Or, another alternative, which could be applied (recursively) to anything made up of smaller parts: maintenance_effort = K1 * coupling_between_parts + sum of maintenance_effort for all parts. For a program, the parts could be global objects and classes. For a class, methods and members. For a method, parameters, statements, and expressions. For an expression, operands and operators.
Your confusion seems to stem from trying to force the maintainability to be a function of only the coupling.
You are right. Moreover, your hypothetical model outline is quite interesting, e.g. to explain preference for a decomposition strategy. Are you aware of any references or known usage? -- Bart Du Bois
No, I just made it up while editing the page. It seems to fit my experience. For example, the tendency for non-OO functions to be longer than OO methods. The classes provide an additional layer of decomposition that can be taken advantage of to limit interactions between program parts, and effectively reduce the possible coupling.