You wrote a function
and put a boolean on the end.
send(order, true)
On the afternoon you wrote it
that true was obvious.
It meant skip the confirmation email.
Eighteen months later
someone reads the same line
and has to go and look,
because true could mean anything.
Urgent.
Dry run.
Retry.
Force.
The call site tells them nothing,
and a call site that tells you nothing
is a call site you copy
without understanding.
That is how the wrong flag
spreads through a codebase.
Look at what the flag
is actually doing inside.
Almost always there is an if
near the top of the body
and two different behaviours below it,
sharing a name
and sharing nothing else.
That is two functions
wearing one signature.
Give them their own names.
send and sendSilently.
Or take a small type instead
of a bare boolean,
so the call site reads
send(order, Notify.NO)
and stops being a riddle.
Then count them.
One boolean is two paths.
Two booleans are four.
Three booleans are eight,
and your tests cover
the two combinations
somebody happened to think of.
The other six are not tested.
They are not even documented.
They exist because the parameters exist,
and one of them
will be reached in production
by a caller who guessed.
There is a version of this
that hides better.
The options object.
Twelve fields, all optional,
each one flipping something,
and no two callers
passing the same shape.
That is not configuration.
That is a function
that never decided what it does.
The fix is not always a rename.
Sometimes the honest answer
is that the caller
should not be choosing at all,
and the flag exists
because two teams disagreed
and nobody wanted the argument.
A parameter is a cheap way
to avoid a decision.
It is also a permanent one.
None of this is about style.
A boolean parameter is a decision
that you moved out of the function
and dropped on every caller,
forever,
in a place where they cannot see
what it costs.
Write the name into the code.
Names survive the meeting
where you explained it.
– Serguey Asael Shinder
Top comments (0)