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:<code>return a # Returns a</code>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.”

Comments should not duplicate the code (D.R.Y)

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.

If you can’t write a clear comment, there may be a problem with the code

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: <code># A dictionary of families who live in each city</code><code>mydict = {</code><code> "Midtown": ["Powell", "Bran"],</code><code> "Norcross": ["Mont"]</code><code>}</code><code>def a(dict):</code><code> # For each city</code><code> for p in dict:</code><code> # If there are no families in the city</code><code> if not mydict[p]:</code><code> # Print it</code><code> print("None.")</code> <code>This script could have been made simpler by using obvious names for variables, functions and collections.</code>

Good comments do not excuse unclear code

Commenting involves placing Human Readable Descriptions inside of computer programs detailing what the Code is doing. Proper use of commenting can make code maintenance much easier, as well as helping make finding bugs faster. Further, commenting is very important when writing functions that other people will use. Remember, well documented code is as important as correctly working code.While it's easy to measure the quantity of comments in a program, it's hard to measure the quality, and the two are not necessarily correlated. A bad comment is worse than no comment at all.

It’s a good idea to comment code that someone else might consider unneeded or redundant, such as this code: <code>final Object value = (new JSONTokener(jsonString)).nextValue(); </code><code>// Note that JSONTokener.nextValue() may return </code><code>// a value equals() to null. </code><code>if (value == null || value.equals(null)) { </code><code> return null; </code><code>}</code> 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.

Explain unidiomatic code in comments

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: <code>// TODO: We are making the decimal separator be a period,</code><code>// regardless of the locale of the phone. We need to think about</code><code>// how to allow comma as decimal separator, which will require</code><code>// updating number parsing and other places that transform numbers to strings</code> Using a standard format for such comments helps with measuring and addressing technical debt.

Use comments to mark incomplete implementations

Most programmers use code that they find online. Including a reference to the source enables future readers to get the full context, such as:<ul><li>what problem was being solved</li><li>who provided the code</li><li>why the solution is recommended</li><li>what commenters thought of it</li><li>whether it still works</li></ul>For example, compare the follwowing pieces of code:<code>/** Converts a Drawable to Bitmap. via https://stackoverflow.com/a/46018816/2219998. */</code> <code>and</code> <code>// Magical formula taken from a stackoverflow post, reputedly related to </code><code>// human vision perception. </code><code>return (int) (0.3 * red + 0.59 * green + 0.11 * blue);</code>

Provide links to the original source of copied code

"Programs must be written for people to read and only incidentally for machines to execute."

Comments should be added not just when initially writing code but also when modifying it, especially fixing bugs. Consider this comment: <code>// NOTE: At least in Firefox 2, if the user drags outside of the browser window,</code><code>// mouse-move (and even mouse-down) events will not be received until</code><code>// the user drags back inside the window. A workaround for this issue</code><code>// exists in the implementation for onMouseLeave().</code><code> @Override public void onMouseMove(Widget sender, int x, int y) { .. }</code> <code>This helps the reader understand the code and it is helpful for determining whether the code is still needed.</code>