[h2s]

Never write comments that re-state the implementation.

    # Try to read the configuration file.

If this wasn't already obvious without the comment, then the code is a mess. Tidy the code up instead of painting over the problem with comments.

[aaronem]

That's a rule to be applied with a bit of nuance. Some things, especially in languages like Perl whose syntax already reads like a half-deliberate attempt to force an obscurantist style on the programmer, can't be made really obvious without doubling or tripling the length of the code in which they're implemented, something which imposes its own cost in readability and maintainability. In cases like that, it can be useful to add a few comment lines which briefly restate what the code implements, as both an aide-memoire for the original developer, and a minimal but immediately accessible answer to the question of "what the hell is this doing?" on the part of those who follow.

[robinh]

I agree wholeheartedly. The syntax doesn't even have to be extremely obscure, it can be highly useful in lower-level languages such as C as well: Often, I just want to get a quick idea of what the next big block of code is going to do without having to read the entire block of code.

[derefr]

I would think that a comment re-summarizing the function in natural language would also "double or triple the length of the code." Wouldn't it be better, then, to just let the code itself expand, rather than expecting maintenance programmers to both read your comments, and then use them to parse an otherwise-inscrutable construction?

[cema]

I think another exception (in addition to the already mentioned help with an otherwise difficult syntax) is when comments are used to visually represent logical segments of the code. Some style guides suggest to write these in all caps. Eg:

  # CONFIG
  ...
  # LOCALS
  ...
  # EDGE CASES
  ...
  # REFORMAT INPUT
  ...
  # MAIN ALGORITHM
  ...

Etc.

[h2s]

Rather than an exception, I think this is an example of the precise scenario in which it's most inappropriate to use comments.

    > visually represent logical segments of the code

This is exactly the use case in which function definitions excel. Use functions for this, not comments.

[akkartik]

Yeah. A past HN discussion caused me to realize that comments are often used for two independent purposes: structure and commentary. Conflating the two has caused many conversations with the participants talking past each other.

http://akkartik.name/post/2012-11-24-18-10-36-soc

[err4nt]

Maybe this is because I come from an HTML + CSS background, but if I'm adding code to a file that may need to be moved around within that file or transplanted to another file I often use comments to mark the start and finish of Sachs ection or 'block' of code.

It has little to do with how clean the code is, I can't imagine not having my way finding markers around!

[Hansi]

Agreed. I often try to make the point that when commenting people in my group should focus more on commenting on WHY and HOW rather than WHAT that is normally easily read from the code.

[streetnigga]

Such commentary goes at the top of a function or class. You get more nuanced as you delve deeper into the textual abyss.