Good code comments only describe why the code is (or isn’t!) doing something.
When teaching coding or reviewing code, I sometimes encounter comments describing what it’s doing, and those are almost always harmful.
To be clear, I’m talking about code comments, not documentation comments. This nuance is different in every language and setup, but for Go, this is it:
In some code, things are done for non-intuitive reasons. It’s worth pointing that out - it makes your code easier to read for a newcomer trying to understand why it’s written that way. In this example, technically
sumOfIntsWithThreshold will work absolutely correctly without its input being sorted, but it turns out that it will be faster if it is.
Other good “why” examples are code being written in a less-intuitive way to make a particular test possible or to avoid a specific edge-case - be sure to note what those are.
If a well-researched algorithm is being used, definitely add a reference to it, including the best URL you have for someone who wants a quick overview of how it works.
Document “why not”
In some code, the reader might see something missing, a pattern apparently broken. Sometimes this is for a good reason, as keeping with the pattern would cause a bug. More specifically, you might be fixing a bug by breaking the pattern.
In this example, especially if you’re removing a line
sort.Strings(c), it’s a good idea to leave a comment explaining why it shouldn’t be there.
Don’t document “what” when it’s trivial
You might be asking yourself “what’s the harm in a comment if it isn’t needed. The answer is that it can be misleading; code will function correctly even if it’s out-of-sync with its comments, so comments aren’t always updated when code is changed, leading to this canonical example:
In less-trivial cases, the reader can be left scratching their head for far longer than they would’ve if the comment weren’t there in the first place.
Documenting “sections” is a code smell
If your code looks is divided using comments into “sections”, it’s probably long and difficult to reason about:
This gets even messier if you don’t sneakily omit error handling. In any case, the section headers are reasonable (albeit not great) candidates for function names:
ServeSite function is now much easier to read. The “section names” are now function names, and are less likely to fall out of date. And as a bonus, the scope of many variables is reduced - so the reader doesn’t have to keep them in mind, and we can use short names for them.
Don’t leave code scars around
Finally, just a pet peeve - while it’s absolutely fine to “comment out” code while developing, you usually shouldn’t commit this to version control. I like calling these “code scars”:
In this case,
x = 3 was there for testing “what if
getMaxValue returns 3”. You should not commit this. However, a possible exception can be if you’re documenting “why not” as above - if it comes with an explanation.
Code is meant to be read by machines and humans, with comments generally being intended for humans to read. Therefore, all of these should be taken as guidelines rather than gospel. Hopefully this post can be of some use for people trying to reason about comment etiquette, or perhaps for code reviewers wanting to point their reviewees at a preexisting summary.