Asking as a newbie programmer: how do you suggest we write comments that explain the ‘why’ part of the code? I understand writing comments explaining the ‘what’ part makes them redundant, but I feel like writing it the former way isn’t adding much help either. I mean, if I created code for a clock, is writing “It helps tell what time it is” better than writing “It is a clock” ?
It would really help if someone could give a code snippet that clearly demonstrates how commenting the ‘correct’ way is clearly better than the way we are used to.
I recognize three kinds of comments that have different purposes.
The first kind are doc block comments. These are the ones that appear above functions, classes, class properties, methods. They usually have a distinct syntax with tags, like:
/*
* A one-line description of this function's job.
*
* Extra details that get more specific about how to use this function correctly, if needed.
*
* @param {Type} param1
* @param {Type} param2
* returns {Type}
*/functionaFunctionThatDoesAThing(param1, param2) {
// ...
}
The primary thing this is used for is automatic documentation generators. You run a program that scans your codebase, looks for these special comments, and automatically builds a set of documentation that you could, say, publish directly to a website. IDEs can also use them for tooltip popups. Generally, you want to write these like the reader won’t have the actual code to read. Because they might not!
The second kind is standalone comments. They take up one or more lines all to themselves. I look at these like warning signs. When there’s something about the upcoming chunk of code that doesn’t tell the whole story obviously by itself. Perhaps something like:
/* The following code is written in a weird way on purpose.
I tried doing <obvious way>, but it causes a weird bug.
Please do not refactor it, it will break. */
Sometimes it’s tempting to use a standalone comment to explain what dense, hard-to-read code is doing. But ideally, you’d want to shunt it off to a function named what it does instead, with a descriptive doc comment if you can’t cram it all into a short name. Alternatively, rewrite the code to be less confusing. If you literally need the chunk of code to be in its confusing form, because a less confusing way doesn’t exist or doesn’t work, then this kind of comment explaining why is warranted.
The last kind are inline comments. More or less the same use case as above, the only difference being they appear on the same line as code, usually at the very end of the line:
dozen = 12 + 1; // one extra for the baker!
In my opinion, these comments have the least reason to exist. Needing one tends to be a signal of a code smell, where the real answer is just rewriting the code to be clearer. They’re also a bit harder to spot, being shoved at the ends of lines. Especially true if you don’t enforce maximum line length rules in your codebase. But that’s mostly personal preference.
There’s technically a fourth kind of comment: commented-out code. Where you select a chunk of code and convert it to a comment to “soft-delete” it, just in case you may want it later. I highly recommend against this. This is what version control software like Git is for. If you need it again, just roll back to it. Don’t leave it to rot in your codebase taking up space in your editor and being an eyesore.
My comment game has gotten far better since I started doing live code reviews. Essentially I ask myself, “Would I feel the need to explain this to someone during a code review?” and if the answer is yes I add a comment.
IMO, the most important parts are to document the actual intent of the code. The contract of what is being documented. Sure, it’s only so useful in perfectly written code, but NO code is perfect, and few will come through later with full context already learned.
It makes it sooo mich easier to know what is intended behavior and what is an unchecked edge case or an unexpected problem. If it’s a complicated thing with a lot of fallout, good documentation can save hours of manually lining up consequences and checking through them for sanity.
You might say, “but that’s indication of bad code!”. No. Not really. Consequences easily extend past immediate code doing things as trivial as saving data to the database without filtering, or having a publicly available service. Even perfectly coded things come up with vulnerabilities all the time due to underlying security issues. It’s always great to have an immediate confirmation of what’s supposed to happen whether it’s immediate code or some library with a new quirk in a new version.
“Why” comments make more sense as application complexity grows.
You also have to consider interaction of the code with other external systems - sometimes external APIs force you to write code in ways you might not otherwise and it’s good to leave a trail for others on your team (and your future self…) about what was going on there.
100%. I also like to leave comments on bug fixes. Generally the more difficult the fix was to find, the longer the comment. On a couple gnarly ones we have multiple paragraphs of explanation for a single line of code.
Asking as a newbie programmer: how do you suggest we write comments that explain the ‘why’ part of the code? I understand writing comments explaining the ‘what’ part makes them redundant, but I feel like writing it the former way isn’t adding much help either. I mean, if I created code for a clock, is writing “It helps tell what time it is” better than writing “It is a clock” ?
It would really help if someone could give a code snippet that clearly demonstrates how commenting the ‘correct’ way is clearly better than the way we are used to.
I recognize three kinds of comments that have different purposes.
The first kind are doc block comments. These are the ones that appear above functions, classes, class properties, methods. They usually have a distinct syntax with tags, like:
/* * A one-line description of this function's job. * * Extra details that get more specific about how to use this function correctly, if needed. * * @param {Type} param1 * @param {Type} param2 * returns {Type} */ function aFunctionThatDoesAThing(param1, param2) { // ... }The primary thing this is used for is automatic documentation generators. You run a program that scans your codebase, looks for these special comments, and automatically builds a set of documentation that you could, say, publish directly to a website. IDEs can also use them for tooltip popups. Generally, you want to write these like the reader won’t have the actual code to read. Because they might not!
The second kind is standalone comments. They take up one or more lines all to themselves. I look at these like warning signs. When there’s something about the upcoming chunk of code that doesn’t tell the whole story obviously by itself. Perhaps something like:
/* The following code is written in a weird way on purpose. I tried doing <obvious way>, but it causes a weird bug. Please do not refactor it, it will break. */Sometimes it’s tempting to use a standalone comment to explain what dense, hard-to-read code is doing. But ideally, you’d want to shunt it off to a function named what it does instead, with a descriptive doc comment if you can’t cram it all into a short name. Alternatively, rewrite the code to be less confusing. If you literally need the chunk of code to be in its confusing form, because a less confusing way doesn’t exist or doesn’t work, then this kind of comment explaining why is warranted.
The last kind are inline comments. More or less the same use case as above, the only difference being they appear on the same line as code, usually at the very end of the line:
dozen = 12 + 1; // one extra for the baker!In my opinion, these comments have the least reason to exist. Needing one tends to be a signal of a code smell, where the real answer is just rewriting the code to be clearer. They’re also a bit harder to spot, being shoved at the ends of lines. Especially true if you don’t enforce maximum line length rules in your codebase. But that’s mostly personal preference.
There’s technically a fourth kind of comment: commented-out code. Where you select a chunk of code and convert it to a comment to “soft-delete” it, just in case you may want it later. I highly recommend against this. This is what version control software like Git is for. If you need it again, just roll back to it. Don’t leave it to rot in your codebase taking up space in your editor and being an eyesore.
My comment game has gotten far better since I started doing live code reviews. Essentially I ask myself, “Would I feel the need to explain this to someone during a code review?” and if the answer is yes I add a comment.
IMO, the most important parts are to document the actual intent of the code. The contract of what is being documented. Sure, it’s only so useful in perfectly written code, but NO code is perfect, and few will come through later with full context already learned.
It makes it sooo mich easier to know what is intended behavior and what is an unchecked edge case or an unexpected problem. If it’s a complicated thing with a lot of fallout, good documentation can save hours of manually lining up consequences and checking through them for sanity.
You might say, “but that’s indication of bad code!”. No. Not really. Consequences easily extend past immediate code doing things as trivial as saving data to the database without filtering, or having a publicly available service. Even perfectly coded things come up with vulnerabilities all the time due to underlying security issues. It’s always great to have an immediate confirmation of what’s supposed to happen whether it’s immediate code or some library with a new quirk in a new version.
“Why” comments make more sense as application complexity grows.
You also have to consider interaction of the code with other external systems - sometimes external APIs force you to write code in ways you might not otherwise and it’s good to leave a trail for others on your team (and your future self…) about what was going on there.
100%. I also like to leave comments on bug fixes. Generally the more difficult the fix was to find, the longer the comment. On a couple gnarly ones we have multiple paragraphs of explanation for a single line of code.