Best practices for writing code comments

Your comments should be D.R.Y. The acronym stands for the programming maxim “Don’t Repeat Yourself.” This means that your code should have little to no redundancy. You don’t need to comment a piece of code that sufficiently explains itself. For example:

return a # Returns a

We can clearly see that 'a' is returned, so there’s no need to explicitly state this in a comment. It adds no information whatsoever and incurs a maintenance cost. This makes comments W.E.T., meaning you “wrote everything twice.”

A misuse of comments is to provide information that should have been in the code. An example is when someone names variables badly and then tries to add comments describing them:

# A dictionary of families who live in each city

mydict = {

"Midtown": ["Powell", "Bran"],

"Norcross": ["Mont"]

}

def a(dict):

# For each city

for p in dict:

# If there are no families in the city

if not mydict[p]:

# Print it

print("None.")

This script could have been made simpler by using obvious names for variables, functions and collections.

The most infamous comment in the Unix source code is “You are not expected to understand this,” which appeared before some hairy context-switching code. It turned out that Dennis Ritchie and co-author Ken Thompson didn’t understand it themselves and later had to rewrite it.

Warning readers away from your code is like turning on your car’s hazard lights: an admission that you’re doing something you know is illegal. Instead, rewrite the code to something you understand well enough to explain or, better yet, that is straightforward.

It’s a good idea to comment code that someone else might consider unneeded or redundant, such as this code:

final Object value = (new JSONTokener(jsonString)).nextValue();

// Note that JSONTokener.nextValue() may return

// a value equals() to null.

if (value == null || value.equals(null)) {

return null;

}

Without the comment, someone might “simplify” the code or view it as a mysterious but essential incantation. Save future readers time and anxiety by writing down why the code is needed.

Most programmers use code that they find online. Including a reference to the source enables future readers to get the full context, such as:

• what problem was being solved
• who provided the code
• why the solution is recommended
• what commenters thought of it
• whether it still works

For example, compare the follwowing pieces of code:

/** Converts a Drawable to Bitmap. via https://stackoverflow.com/a/46018816/2219998. */

and

// Magical formula taken from a stackoverflow post, reputedly related to

// human vision perception.

return (int) (0.3 * red + 0.59 * green + 0.11 * blue);

Comments should be added not just when initially writing code but also when modifying it, especially fixing bugs. Consider this comment:

// NOTE: At least in Firefox 2, if the user drags outside of the browser window,

// mouse-move (and even mouse-down) events will not be received until

// the user drags back inside the window. A workaround for this issue

// exists in the implementation for onMouseLeave().

@Override public void onMouseMove(Widget sender, int x, int y) { .. }

This helps the reader understand the code and it is helpful for determining whether the code is still needed.

Sometimes it’s necessary to check in code even though it has known limitations. While it can be tempting not to share known deficiencies in one’s code, it is better to make these explicit, such as with a TODO comment:

// TODO: We are making the decimal separator be a period,

// regardless of the locale of the phone. We need to think about

// how to allow comma as decimal separator, which will require

// updating number parsing and other places that transform numbers to strings

Using a standard format for such comments helps with measuring and addressing technical debt.