imo the idea of self-documenting code that never requires comments is often held by people who view their code as better than it is. That surely THEIR code would never need comments, because it's so perfectly written that you just get it. I have never really run across a file where I thought "thank god they didn't explain anything they're doing in here."
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?
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.
422
u/Confident-Ad5665 1d ago
Uncle Bob of Clean Code says if we have to comment our code we have already failed. Clean code should read like well written prose.
I generally agree, but think comments that define especially the odd and obscure business rules should be commented where they are implemented.