How to measure coupled code

Back in March, I wrote about dependency injection. I explained why you should be injecting your dependencies instead of creating them on the fly. I argued that dependency injection was a great technique for decoupling your code. It is!

We all seem to realize that coupled code is bad and that we should work to keep our code decoupled. And we all have had those terrible experiences where you change some code in a module that does order processing, and suddenly the credit report is all screwed up.

But what the heck does it mean, exactly, to have “coupled code”? How do we tell? How do we know if our code is lightly coupled, medium coupled, or heavily coupled? 

We all know that we should try to reduce coupling and make different parts of code less dependent on each other so that changes in one part don’t affect functionality in another.  Heavy coupling leads to fragile systems and hidden landmines that go off when we least expect them. 

Connascence? What?

Well, there is a word for this notion—connascence. The term was formalized and popularized by Meilir Page-Jones in his 1995 book What Every Programmer Should Know About Object-Oriented Design. In that book, Page-Jones took the notion of coupling a step further by coming up with a way to measure it. 

Connascence is when two parts of code are so connected that if you change one, you have to change the other to keep things working. A simple example of connascence is adding a parameter to an existing method. If you change the signature of a method, you have to change the code everywhere you call that method. 

It’s a basic notion, one that you probably understand without formally considering it. However, the closer you look at connascence, the more interesting (and complex) it gets. Connascence becomes a measure of the type and severity of coupling that can occur in your code. 

Another way to think of it is that coupling is graded on a scale. There are different degrees and severities of coupling, and connascence is the measure of how extensively and how strongly code is coupled together. Code has to be coupled to work, but you want to couple your code with a low level of connascence. 

How about an example? Consider the following code.

function saveUser(name: string, age: number, isAdmin: boolean) {
  //...write to DB
}

You might not think that this code is coupled to much of anything, but it is. First, the user of this code needs to know the types of the parameters as well as their order. She also needs to know what isAdmin means. These may seem like nitpicks, but imagine a function that had more parameters or more mysterious names. These couplings are subtle, but they are there. 

Loosening the couples

How about we clean things up a bit?

interface User {
name: string;
age: number;
role: 'admin' | 'user';
}

function saveUser(user: User) {
//...write to DB
}

This is slightly better. The caller needs to understand or figure out only one thing, the User interface. There is no order of parameters to worry about, and the notion of isAdmin is much clearer (and expandable) as role. Page-Jones created an entire taxonomy of connascence to describe these kinds of code relationships and help us manage them. Connascence also helps us think about two crucial dimensions: how strong the coupling is, and how far apart the coupled pieces live. Coupling between two routines in the same object is normal. But when coupling spans modules or services, it becomes a serious problem.

Connascence gives you a sharper vocabulary to describe coupling, and a new way to look at your code. Next week, we’ll dive into the taxonomy and start naming the different kinds of coupling you’re already living with.