[QUOTE="Malcolm McLean"]\nYou're assuming that we can find programmers with English literature degrees\nwho understand clear communication, and also of course technical degrees\nso they understand the mathematical side of what they are doing.[/QUOTE]\n\nNo I'm not.\n[QUOTE]\nYou can maybe get the odd such person. But, generally, a name like\nEnableControl() is meaningful to the person writing the function. Enabling\nshares substantial logic with disabling, so it's easier to provide the same\nfunction. And we've only got one control.\nBut to the maintaining programmer\n\nEnableControl(0);\n\nmight mean "enable control with index zero". He knows we've\nonly got one control. Fair enough, that's in for expansion.\n\nI chose EnableControl() because it's a common real example. Plenty of APIs\nhave it.\n\nWith software engineering, the trivial is important. It's not so much than\nany one feature is unacceptably bad. It's the interaction of such features.\n\nConsider this.\n\nSetControlState(CONTROL_DISABLED);\n\nacceptable, but a bit confusing, because you can't pass anything except\nCONTROL_ENABLED or CONTROL_DISABLED.\n\nNow\n\nSetControlState(true);\n\nthe reader is completely in the dark. The bool has interacted with a poor\nchoice of name to make something very confusing.[/QUOTE]\n\nI still don't get it. Why is SetControlState(true) any more confusing\nthat SetControlState(1) or SetControlState(42)?\n\nI argued that this is a general problem: magic constants are almost\nalways a bad idea and that applies to true and false as much as to 0 or\n42. I made a subsidiary remark that there are some cases where we don't\nmind: i+1 and set_bit(n, true) both seem reasonable to me.\n\nIs your point that API designers are somehow tempted into not providing\nexplanatory names for some Boolean parameters where they would have\nthought to do so for integer ones? If so, I won't argue the point -\-\nthat may be the case, and I have no evidence one way or the other.