Malcolm McLean said:People aren't machines.
You mean that they are more complex machines than the ones we make.
They'll pass "true" or "false" to a function because it's already a
It is because they are "not machines" that they should be able to think
about what other human readers will make of their code. A thoughtful
programmer will see that 'true' is exactly as descriptive as 42 -- no
more and no less. Are there some who will pepper their code with 42s
regardless of good practice? Yes. Are there some who will give 42 a
name but yet still pass true and false where the meaning is unclear?
Apparently there are. The advice should be to include all such
constants in the advice about not having magic constants in code.
They'll use bool as a parameter and not provide any defined #constants
because it's obvious that EnableControl(true) means enable it and
EnableControl(false) means disable it.
And in that case they are correct. There is no need to name those
instances. There are analogous situations for other types as well. You
will find good quality code that has i+1 and j-1 in it. The context
will often remove the need to name the constant. It's a judgement made
by people who are not acting like machines.
After all, the other way round
would be silly. They can't make the leap to the poor person totally unfamiliar
with the API who sees EnableControl(false) embedded in a long and confusing
function which is somehow setting the control to the wrong state.
OTOH if you have #define CONTROL_ENABLE 42 few people will pass a raw
I don't get this point at all. Why would you do that? Are you giving
an example of a bad API in order to make some general point?