> You have a tendency to overengineer things. Overengineering is an actual problem. For a tiny example, I'll see things like: enum MAGIC = 67; // explanation ... foo(MAGIC); The use of MAGIC is the only one, and is far removed. A better solution is: foo(67); // explanation because it improves locality. I also see things like an object fleshed out with all kinds of member functions that are never used.
If `MAGIC` was sufficient to understand what the significance of the number was and `// explanation` was the citation or derivation, then I'd be fine with this, especially if there were a bunch of other constants with explanations with similar derivations or citations (eg a bunch of trig or constants from the same standard); then it'd be preserving a different sort of locality.
If `MAGIC` wasn't sufficient to capture the purpose of the constant & such a name wasn't readily available, so that you're always going to want to read `// explanation` (rather than only in the case you think the value is wrong), then I'd agree with you.
Concrete(ish) examples: if 67 terminated the Foo section of the Bar binary file format, even if we only used it once, I'd prefer to see END_OF_FOO rather than read a comment. Reading comments is context switching, at least for me. Names help me stay in the headspace of the programming language.
If 67 was the result of an ad-hoc calculation which only made sense in the context of this particular program (how many angels can dance on the head of an Acme brand pin executing our trademarked choreography) while, and so there wasn't a great name for that calculation, or at least not a name that would make sense unless you've already read the derivation, then I'd agree in that case.
That being said, I have absolutely seen overengineering or misengineering cause real problems.