The theoretically optimal values are:
- Maintainability index: 100. Higher values indicate better maintainability.
- Cyclomatic complexity: 1. The number of different paths that code can take.
- Depth of inheritance: 1. The number of class definitions above this one in the inheritance tree, not including interfaces.
- Class coupling: 0. Number of other entities this entity is dependent on.
There are no hard and fast “good” ranges, though it’s possible to make some general statements.
- Having high per-method cyclomatic complexity suggests a method is getting too complicated.
- Having an inheritance depth more than about 3 or 4 (of your own classes, not the framework’s) is a trouble sign that you may be unnecessarily representing abstract relationships that aren’t really in your software’s domain.
- Low class coupling is in general better, but sometimes it’s unavoidable. To the extent possible, you should definitely minimize the dependency between namespaces, since there’s much less reason for dependencies here.
A project could only reach all four values simultaneously by essentially doing nothing and being useless: software that does nothing and depends on nothing is certainly maintainable, but not a very good use of client dollars.
Therefore, all complexity is a tradeoff: additional so-called inherent complexity encodes more sophistication into the program, allowing it to expand the feature set. What you would like to avoid is accidental complexity introduced by a poor or deficient implementation.