Curlyâs Law: Do One Thing
In Outliving the Great Variable Shortage, Tim Ottinger invokes Curlyâs Law:
A variable should mean one thing, and one thing only. It should not mean one thing in one circumstance, and carry a different value from a different domain some other time. It should not mean two things at once. It must not be both a floor polish and a dessert topping. It should mean One Thing, and should mean it all of the time.
The late, great Jack Palance played grizzled cowboy Curly Washburn in the 1991 comedy City Slickers. Curlyâs Law is defined in this bit of dialog from the movie:
Curly: Do you know what the secret of life is?
Mitch: No, what?
Curly: This. [holds up one finger]
Mitch: Your finger?
Curly: One thing. Just one thing. You stick to that and everything else donât mean shit.
Mitch: That's great, but what's the âone thing?â
Curly: [smiles] Thatâs what you gotta figure out...
Curlyâs Law, Do One Thing, is reflected in several core principles of modern software development:
- Donât Repeat Yourself
If you have more than one way to express the same thing, at some point the two or three different representations will most likely fall out of step with each other. Even if they donât, youâre guaranteeing yourself the headache of maintaining them in parallel whenever a change occurs. And change will occur. Donât repeat yourself is important if you want flexible and maintainable software. - Once and Only Once
Each and every declaration of behavior should occur once, and only once. This is one of the main goals, if not the main goal, when refactoring code. The design goal is to eliminate duplicated declarations of behavior, typically by merging them or replacing multiple similar implementations with a unifying abstraction. - Single Point of Truth
Repetition leads to inconsistency and code that is subtly broken, because you changed only some repetitions when you needed to change all of them. Often, it also means that you havenât properly thought through the organization of your code. Any time you see duplicate code, thatâs a danger sign. Complexity is a cost; donât pay it twice.
Although Curlyâs Law definitely applies to normalization and removing redundancies, Do One Thing is more nuanced than the various restatements of Do Each Thing Once outlined above. It runs deeper. Bob Martin refers to it as The Single Responsibility Principle:
The Single Responsibility Principle says that a class should have one, and only one, reason to change. As an example, imagine the following class:
class Employee { public Money calculatePay() public void save() public String reportHours() }This class violates the SRP because it has three reasons to change:
- The business rules having to do with calculating pay.
- The database schema.
- The format of the string that reports hours.
We dont want a single class to be impacted by these three completely different forces. We dont want to modify the Employee class every time the accounts decide to change the format of the hourly report, or every time the DBAs make a change to the database schema, as well as every time the managers change the payroll calculation. Rather, we want to separate these functions out into different classes so that they can change independently of each other.
Curlyâs Law is about choosing a single, clearly defined goal for any particular bit of code: Do One Thing. That much is clear.
But in choosing one thing, you are ruling out an infinite universe of other possible things you could have done. Curlyâs Law also means consciously choosing what your code wonât do. This is much more difficult than choosing what to do, because it runs counter to all the natural generalist tendencies of software developers. It could mean breaking code apart, violating traditional OOP rules, or introducing duplicate code. Itâs taking one step backward to go two steps forward.
Each variable, each line of code, each function, each class, each project should Do One Thing. Unfortunately, we usually donât find out what that one thing is until weâve reached the end of it.