- The code 'tells you' what it does
- The comment for the code tells you what the author intended it to do.
The gap between the two is where bugs can be found.
Not quite.
The comment for the code tells you what the author of the comment understood the code to do when hen wrote the comment.
I don't write what the code does or even what "I understand the code to do". I explain choices, especially ones that the next developer or my future self is likely to misunderstand when looking at the code.
I've always said coding is a cottage industry!
It's luckily rare for people to add wrong comments, though (and those who do should be publicly fustigated).
By the way, please never state something as it were the truth if you're not sure that it is. Saying "I think" is perfectly fine, and might save people days of investigation.
I've seen 64 character variable names
Names should be mnemonic. Reminding, not describing
There's vanishingly few cases where this extra logging statements will ever be a problem and they can all be handled autonomously if they ever are - but it will save everyone else a ton of time in deployment.
Re: busy, no because I only enable debug logging when I need it
Re: loops, I wrote a deduplicating logger, so if there are 200 identical messages from within a loop I see:
{event: "thing happened"}
{event: "thing happened",
duplicates: 100,
since: "2024-09-11T01:05:00Z",
reason: "count reached"}
I think it's important to log the first one immediately, just in case you want to alert on that message. It wouldn't do to wait for the other 99 before raising the alarm.
I wrap my loggers in deduplicators only when I'm about to hand them off to a loop. Otherwise it's the normal ones.
The point is there's a big difference between "we've got a problem, we need to add logging and redeploy to try and isolate it" versus "we might have a problem, bump the logging level up on that service to see what's going on" (which with the right system you can do without even restarting).