AC:"The goal is to make it so that anyone reading the class for the first time
with no prior experience can understand its purpose and basic function
without having to spend 5 minutes deobfuscating the code.That said, for
personal consumption code, I don't generally bother going to that much effort
to make my code clean/clear.
and ^^ That said, I do the same for my personal code -- since maybe 10-15 years back when I started seeing code that I'd written 2-5 years before that I knew I had written, but looked totally foreign to me. As time has gone on and I write code that builds on code that builds on more code (much going into libs), AND as I am forced by ever changing priorities to work on more projects in "parallel" (meaning I have more projects that have unfinished code waiting for more attention), I find that even spending a few months away from some code and I realize I didn't leave myself enough signposts to spend 'no-time' getting back up to speed.
The 2nd big point of this discussion is who decides what is "unnecessary" and what removal of "extra code" doesn't violate the premise that premature optimization is, at least, in the top 5 time-wasters category? I had a Dilbertian-boss, who only wanted bugs fixed that were reported by paying customers, and didn't want pre-release stress testing on multi-threaded kernel code ("Today's untested code can become tomorrow's paycheck."), but using short-term solutions for short-term OS-limitations was bad -- especially if documented. I.e. estimated time before limitation was removed: 2-3 years (was actually 18 months). Condition necessary to hit the "design-flaw": 25-30 years of continuous system *uptime* (no reboots or crashes). Admittedly this wasn't windows, but