Long time ago I wrote...
# If you require a comment for this function you should not be updating this code
...followed by a simple 1-line function
Took 5 years but today someone finally called me out on my snark. My defense was "But it's true. Anyone who doesn't understand that on sight shouldn't be updating that code unsupervised."
Can't wait for this person to find the comment "# This next part is pure, 100% security theater but mandatory per policy"
OK, now I'm being lectured on the purpose of comments in code.
Thing is, above a certain level of fluency, all code is self-documenting. Bottom line is that comments are to help people who haven't reached that level of fluency in that language.
But there's a fluency floor below which unsupervised work is an operational risk. Someone who doesn't get that 1-line of basic code and for whom the function name 'tolower' isn't a big enough clue shouldn't be mucking about in code the team uses daily.
I always tell prospective consulting clients a few jokes during the interview to test company culture.
Example: When a certain cable company asked what time I would be on-site that Monday, I told them "Between 8am and noon, or between noon and 5pm."
They were not amused.
Predictably, it didn't work out.
Going forward I'm giving prospects a list of code comments I've written and ask if they object to any of them.
@thereal_renaissance_man I am imagining a script that analyzes the code and inserts snippits as required to meet the threshold. ;-)
@tdotrob
"This is a while loop that repeats until TRUE equals FALSE."
@tdotrob
I have been known to quote Monty Python in comments, at length, when I've been required to fulfill insanely arbitrary loc-to-comment ratios. You know good and useful comments when you encounter them - arbitrarily requiring a certain amount of comments just leads to wasted confusion - much like The Parrot Sketch.