Malcolm McLean said:You're assuming that we can find programmers with English literature degrees
who understand clear communication, and also of course technical degrees
so they understand the mathematical side of what they are doing.
No I'm not.
You can maybe get the odd such person. But, generally, a name like
EnableControl() is meaningful to the person writing the function. Enabling
shares substantial logic with disabling, so it's easier to provide the same
function. And we've only got one control.
But to the maintaining programmer
might mean "enable control with index zero". He knows we've
only got one control. Fair enough, that's in for expansion.
I chose EnableControl() because it's a common real example. Plenty of APIs
With software engineering, the trivial is important. It's not so much than
any one feature is unacceptably bad. It's the interaction of such features.
acceptable, but a bit confusing, because you can't pass anything except
CONTROL_ENABLED or CONTROL_DISABLED.
the reader is completely in the dark. The bool has interacted with a poor
choice of name to make something very confusing.
I still don't get it. Why is SetControlState(true) any more confusing
that SetControlState(1) or SetControlState(42)?
I argued that this is a general problem: magic constants are almost
always a bad idea and that applies to true and false as much as to 0 or
42. I made a subsidiary remark that there are some cases where we don't
mind: i+1 and set_bit(n, true) both seem reasonable to me.
Is your point that API designers are somehow tempted into not providing
explanatory names for some Boolean parameters where they would have
thought to do so for integer ones? If so, I won't argue the point --
that may be the case, and I have no evidence one way or the other.