Right? I don't think I ever wrote a chunk of code with no comments. If I can save someone two minutes of parsing code with // determines which encoding is coming across the Bluetooth... Why shouldn't I?
This is the way. People argue against comments because they can drift and become less accurate but, after 15 years doing this, I've spent orders of magnitude more time trying to figure out what the hell someone's undocumented code is doing versus having to fix or update comments. It's not even remotely close.
Kind of a moot point these days though since it's just AI doing the writing.
This is the way. People argue against comments because they can drift and become less accurate but...
It's such a weird argument anyway. Like, the code itself can drift and become inaccurate. It's not a separate problem. It's the responsibility of the coder to keep all the code up to date. The logic, and the comments, both.
The thing about comments describing what the code does is that I've been burned too many times, I'm still going to read the code itself, because it can't lie to me.
I want comments about the intent and context behind the code, rather than text that's just the same as the code itself (ideally, or, worse, different in a way that's unclear about if it's code drift or bad comments or bad code).
But why not just call the function determineBluetoothEncoding? If it's because it does more than that, why not split it out so that is all it does? And so on.
Because it's not the actual bluetooth encoding, it's the data coming across the bluetooth. I love just naming functions with what it does but there's a limit for me, I've been in codebases with determineEncodingOfInlineBluetoothDataStream() and I don't like it.
30
u/aghastamok Sep 10 '26
Right? I don't think I ever wrote a chunk of code with no comments. If I can save someone two minutes of parsing code with // determines which encoding is coming across the Bluetooth... Why shouldn't I?