[QUOTE="Malcolm McLean"]\nPeople aren't machines.[/QUOTE]\n\nYou mean that they are more complex machines than the ones we make.\n[QUOTE]\nThey'll pass "true" or "false" to a function because it's already a\ndescriptive identifier.[/QUOTE]\n\nIt is because they are "not machines" that they should be able to think\nabout what other human readers will make of their code. A thoughtful\nprogrammer will see that 'true' is exactly as descriptive as 42 -\- no\nmore and no less. Are there some who will pepper their code with 42s\nregardless of good practice? Yes. Are there some who will give 42 a\nname but yet still pass true and false where the meaning is unclear?\nApparently there are. The advice should be to include all such\nconstants in the advice about not having magic constants in code.\n[QUOTE]\nThey'll use bool as a parameter and not provide any defined #constants\nbecause it's obvious that EnableControl(true) means enable it and\nEnableControl(false) means disable it.[/QUOTE]\n\nAnd in that case they are correct. There is no need to name those\ninstances. There are analogous situations for other types as well. You\nwill find good quality code that has i+1 and j-1 in it. The context\nwill often remove the need to name the constant. It's a judgement made\nby people who are not acting like machines.\n[QUOTE]\nAfter all, the other way round\nwould be silly. They can't make the leap to the poor person totally unfamiliar\nwith the API who sees EnableControl(false) embedded in a long and confusing\nfunction which is somehow setting the control to the wrong state.\n\nOTOH if you have #define CONTROL_ENABLE 42 few people will pass a raw\n42.[/QUOTE]\n\nI don't get this point at all. Why would you do that? Are you giving\nan example of a bad API in order to make some general point?