How bad programmers comment their code. Good programmers don’t comment at all and let the code speak for itself, leaving commenting to some obscure and arcane implementation the coder left in after a week long binge on caffeine and gummy bears.
I was rewriting some old code of mine and ended up stripping out the comments. I kept reading them instead of the code, which I had been changing, and they were irrelevant. (I added new comments back in, though a big reason to rewrite was to make the code more self-explanatory.)
Code should absolutely speak for itself. But the occasional comment is still good to explain the ‘why’ of the code when the why isn’t very obvious, often due to a niche requirement. Also any time you have to break out a hack, that needs comments up the ass, what was the bug, what URL did you find the fix at, why does this hack work, etc etc. It’s very satisfying to go back and remove those hacks after they are no longer needed, often because the underlying technology fixed the bug that had to be hacked around.
How bad programmers comment their code. Good programmers don’t comment at all and let the code speak for itself, leaving commenting to some obscure and arcane implementation the coder left in after a week long binge on caffeine and gummy bears.
This is the truth. In my experience, the people who often writes comments are also writing the most incomprehensible code.
Comments are frequently getting outdated as well, so they’re not in great help understanding the code either.
I was rewriting some old code of mine and ended up stripping out the comments. I kept reading them instead of the code, which I had been changing, and they were irrelevant. (I added new comments back in, though a big reason to rewrite was to make the code more self-explanatory.)
“What does this section of code do?”
Run it and find out, coward.
Nah. It should be obvious by just looking at it in code. If it isn’t, you haven’t extracted single purpose methods out of it yet.
Just having clear and concise variable names often goes a long way. Avoid using abbreviations.
Breaking out the code into functions helps limit the number of variables within a scope, which makes it easier to name them.
Code should absolutely speak for itself. But the occasional comment is still good to explain the ‘why’ of the code when the why isn’t very obvious, often due to a niche requirement. Also any time you have to break out a hack, that needs comments up the ass, what was the bug, what URL did you find the fix at, why does this hack work, etc etc. It’s very satisfying to go back and remove those hacks after they are no longer needed, often because the underlying technology fixed the bug that had to be hacked around.
It definitely feels great when I get to remove the
//hack abc due to bug in library xyz version 1.4.5, issue tracker says it’s fixed in 1.5.0. - link
Yeah, hence me mentioning the arcane code nobody knows what it does.