Local copy of Detailed clarification -> Source
Maintainability is defined as the ease with which a system can be maintained. Maintainability is the ability of the system to undergo changes with a degree of ease. These changes can impact components, services, features, and interfaces when adding or changing the functionality, fixing errors, and meeting new business requirements. It is an internal attribute of the system which cannot be measured directly. Instead, one can measure maintenance process attributes, such as the time required to make a change, which are influenced by software maintainability. Since we are interested to evaluate maintainability during development and at delivery time, these maintenance process measures are available too late. A solution to this problem is to build models to predict the maintenance process measur1es from software product measures like cohesion, coupling and complexity.
- Maintainability Index - Calculates an index value between 0 and 100 that represents the relative ease of maintaining the code. A high value means better maintainability. Color coded ratings can be used to quickly identify trouble spots in your code. A green rating is between 20 and 100 and indicates that the code has good maintainability. A yellow rating is between 10 and 19 and indicates that the code is moderately maintainable. A red rating is a rating between 0 and 9 and indicates low maintainability. For more information, see the Maintainability index range and meaning blog post.
- Cyclomatic Complexity (CC): Cyclomatic complexity is a popular procedural software metric equal to the number of decisions that can be taken in a procedure. Methods where CC is higher than 15 are hard to understand and maintain. Methods where CC is higher than 30 are extremely complex and should be split into smaller methods (except if they are automatically generated by a tool). Recommended threshold value: 20
- Percentage of comments. Code where the percentage of comment is lower than 20% should be more commented. However overly commented code (>40%) is not good as well. This metric is computed with the following formula: PercentageComment = 100*NbLinesOfComment / ( NbLinesOfComment + NbLinesOfCode)
- Efferent Coupling at type level (Ce). The Efferent Coupling for a particular type is the number of types it directly depends on. Notice that types declared in third-party assemblies/libraries are taken into account. Types where TypeCe > 50 are types that depends on too many other types.
- Module coupling - a measure of the strength of the relationships between modules. Table from the reference document can be used.
- Module Strength - a measure of how strongly related are the elements within a module. Maintainability increases with module strength. The design goal is to have modules with informational or functional strength. Table from the reference document can be used.
- A measure of intermodule and intramodule complexity of a system based on fan-out, number of modules and input/output variables. The metric is simple. Of the five information flow metrics, it was validated with the largest industrial experiment, showing good correlation with the number of faults.
- Cocomo Inspired Metric - The effort adjustment factor is the product of fifteen factors, which are divided into four categories: product attributes, computer attributes, personnel attributes, and project attributes. ratings can be assigned to these factors using table 8-3 of boehm's book (page 119). If the value is greater than 1, we predict a high cost of maintenance; if it is smaller, we predict a low cost.
- Type size. How many lines of code are in type definition file. Recommended threshold value: 200
- Cyclomatic complexity <= 20
- Type size <= 200 lines of code
- Percentage of comments: >20% and < 40%
- SonarQube