Comparison
CouplingvsTemporal coupling
Coupling
you changed one module and three tests in a directory you had never opened went red.
How much one part of a system has to know about another part to work. Every dependency is coupling and some of it is necessary; the question in a review is never whether two things are coupled but whether they are coupled through a stable contract or through an assumption that will move. High coupling is what makes a small change expensive, because the cost of the change is not the edit but everything the edit forces you to also understand.
Full entry →Temporal coupling
the call only works if you remember to call the other method first, and nothing tells you that.
A dependency not on what another piece of code does but on when it is called. Two methods that must run in a particular order, an object that must be configured before it is used, a test that passes alone and fails in a suite. It is the hardest coupling to see in review because it is invisible in the type signatures, and it is usually discovered by someone new who called things in the obvious order.
Full entry →