Various metrics can be derived to give insight into code bases, these metrics can aid with technical debt assessments or plan architectural migrations. One such metric is Connascence
Connascence is a concept introduced by Meilir Page-Jones in 1996, it provides developers and architects coupling insight.
Two components are connascent if a change in one would require the other to be modified in order to maintain the overall correctness of the system.
Connascence types are devised into two categories, static and dynamic connascence, one category is concerned with coupling at the source code level and another is concerned with coupling at run-time.
Types of connascence include:
Connascence of Identity: This is a dynamic type of connascence which occurs when several values relate on one another and must change together.
Connascence of Meaning: This is a static type of connascence which occurs when multiple components must agree on the meaning of particular values.
Each connascence instance can have its maintainability impact measured by three properties:
- Strength: Determines the ease of which a type of connascence can be refactored.
- Degree: Relates to the impact size that coupling has on code bases, therefore this is best kept as low as possible. If a component is connascent with a 100 other components then it has a higher coupling impact than a component that is connascent with only a few.
- Locality: Relates to the proximity between modules, where modules far apart should be more loosely coupled than modules that are closer together.
Three guidelines exist for utilizing connascence metrics to improve system modularity:
- Minimize overall connascence by breaking the system into encapsulated elements
Minimize any remaining connascence that crosses encapsulation boundaries
Maximize the connascence within encapsulation boundaries
There are many more useful metrics available:
Cyclomatic complexity: used to indicate the complexity of a program.
Distance from main sequence: used to measure the balance between stability and abstractness, systems that are too abstract become difficult to understand, while systems that are too concrete become difficult to modify.
Many code analysis tools allow for these metrics to be derived without necessarily requiring manual calculations. An example of this is NDepend.