Connascence Properties: Strength, Locality, and Degree Demystified

The Brutal Reality of Software Entropy

Let's be honest: most "clean code" advice is frustratingly vague. We are told to "reduce coupling" as if it's a simple toggle switch, but in the trenches of a massive legacy codebase, every line of code seems to depend on ten others. This is where Connascence moves from academic theory into a vital survival tool. Originally coined by Meilir Page-Jones, connascence provides a rigorous vocabulary for dependency. It isn't just about whether two things are coupled, but how they are coupled and how much that relationship is going to cost you when you inevitably have to change a requirement six months from now.

If you ignore these properties, you aren't just writing code; you are building a house of cards where moving a chair in the kitchen might collapse the roof in the garage. Most developers focus on the "what" of their code, but the "how it breaks" is determined entirely by the strength, locality, and degree of its connections. We need to stop treating coupling as a binary state and start measuring it as a spectrum of risk. High connascence isn't always a "bug," but it is always a debt that must be managed, or it will eventually bankrupt your team's velocity and sanity.

Strength: The Hierarchy of Pain

The Strength of connascence refers to how difficult it is to change a dependency. Think of it as a ladder of technical debt. At the bottom, you have "Connascence of Name," where you simply need to make sure two things call each other by the right identifier. It's easy to refactor and easy to find. At the top, you have "Connascence of Identity," where two components must share the exact same instance of an object to function. As you move up this scale—through Type, Meaning, and Algorithm—the cost of change skyrockets because the relationship becomes more "brittle" and harder for automated tools like IDEs to catch during a rename or a logic shift.

Consider "Connascence of Manual Order," a common but silent killer. This happens when a sequence of function calls must happen in a specific order for the system to remain valid. If you call init() after calculate(), the system crashes. This is a "strong" form of connascence because the dependency is hidden within the execution logic rather than being explicitly defined in the signature. To improve your architecture, your primary goal should always be to refactor "strong" forms of connascence into "weaker" ones, turning hidden logical dependencies into explicit, name-based ones that are easier to manage and less likely to cause a production outage.

// Example of High Strength (Connascence of Position)
// If the order of the array changes, the whole system breaks.
function processUser(userData: any[]) {
    const name = userData[0]; 
    const age = userData[1];
    saveToDatabase(name, age);
}

// Refactored to Weak Strength (Connascence of Name)
// Much more resilient to change.
interface User {
    name: string;
    age: number;
}
function processUserRefactored(user: User) {
    saveToDatabase(user.name, user.age);
}

Locality: Distance Matters

Locality is the property that asks: "How far apart are these two coupled components?" In the world of connascence, distance isn't measured in miles, but in scope. Two functions in the same class have high locality. Two services in different time zones communicating over an unstable API have very low locality. The brutal truth is that strong connascence is perfectly acceptable if the locality is high. If you have a complex, order-dependent algorithm contained entirely within a single private method, it's fine. You can see it all on one screen, and you can change it all at once without breaking the rest of the world.

However, the moment strong connascence leaks across boundaries—across classes, packages, or microservices—you have a disaster waiting to happen. Low locality combined with high strength is the primary cause of "distributed monoliths." This is where you can't deploy Service A without also deploying Service B because they share a secret understanding of a database schema or a specific data format (Connascence of Schema). As a rule of thumb, the further apart two pieces of code are, the weaker the connascence between them must be. If they are far apart, they should only know each other by "Name" or "Type," never by "Algorithm" or "Identity."

Degree: The Power of Many

The Degree of connascence refers to the "magnitude" of the relationship—essentially, how many things are affected by a single connection. A function used in two places has a low degree. A global configuration object used by 400 different modules has a dangerously high degree. Even a weak form of connascence, like Connascence of Name, becomes a nightmare if the degree is high enough. If you want to rename that global config property, you now have to touch 400 files. The risk of human error increases exponentially with the degree, regardless of how simple the actual change appears on the surface.

Brutally speaking, high degree is often a symptom of "God Objects" or poor encapsulation. When a single component becomes the "hub" for too many "spokes," you create a bottleneck for both the software and the developers. Every merge conflict you encounter is usually a manifestation of high degree. To fix this, you must break down these high-degree entities into smaller, more specialized components. By reducing the number of things that care about a specific piece of information, you reduce the surface area of potential bugs and make the system significantly easier to reason about during high-pressure debugging sessions.

The 80/20 Rule of Connascence

You don't need to memorize the entire taxonomy of connascence to see 80% of the benefits. Focus your energy on these two high-impact areas:

Audit your "Distantly Coupled" components: Look for any two modules in different folders or services that share anything more complex than a simple data contract. If they share "Connascence of Meaning" (e.g., both knowing that the magic number 4 means "Canceled"), refactor it immediately.
Kill the Global State: Global variables are the definition of high degree and low locality. By passing dependencies explicitly (Dependency Injection), you move from high-degree/low-locality chaos to low-degree/high-locality order.

By focusing on just these two things, you eliminate the most common sources of "spooky action at a distance" where a change in one corner of the app mysteriously breaks a feature in another. Most developers waste 80% of their time chasing bugs caused by these specific architectural failures. Fix the locality of your strong connections and reduce the degree of your common components, and you'll find that "clean code" actually starts to happen naturally rather than feeling like a chore.

Summary of Key Actions

If you want to apply these principles tomorrow, follow these five steps to sanitize your architecture:

Map the Strength: Identify your most complex dependencies and categorize them. If you find "Manual Order" or "Algorithm" connascence, mark it for refactoring.
Verify Locality: Ensure that any "Strong" connascence is confined within a single file or class. If it crosses a boundary, it's a high-priority architectural debt.
Reduce the Degree: Look for "Popular" classes or functions. Break them apart so that fewer components depend on any single piece of logic.
Prefer Names over Positions: In your APIs and functions, use named objects or dictionaries instead of long lists of positional arguments or arrays.
Encapsulate the "Why": When two things must change together, try to wrap them in a single parent component so the connascence becomes "local" rather than "distributed."