Comments should be sentences

http://nedbatchelder.com/blog/201401/comments_should_be_sentences.html

by henrik_w • 13 years ago

42 49 13 years ago

h2s2• 13 years ago

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.

aaronem2• 13 years ago

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.

robinh2• 13 years ago

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• 13 years ago

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?

cema3• 13 years ago

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.

h2s2• 13 years ago

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.

akkartik3• 13 years ago

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• 13 years ago

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!

streetnigga• 13 years ago

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

Hansi• 13 years ago

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.

brudgers2• 13 years ago

Literate comments are as a gateway drug to literate programming.

cema3• 13 years ago

True. However, how useful literate programming is depends on a number of factors, time often being the main limiting factor.

taeric3• 13 years ago

I've found tooling is the main limiting factor. Time certainly doesn't help, but seeing as how I couldn't use literate programming while my colleagues use their IDEs is ultimately what means I will be ditching it once I get help on things.

brudgers2• 13 years ago

If you're writing code that can be so easily understood that it does not require explanation, get a machine to do it.

shizzy04• 13 years ago

Cue the self-documenting, we-don't-need-no-stinking-comments rabble rousers in 3, 2, 1...

AND that's one reason why we're not an actual profession, people.

vezzy-fnord2• 13 years ago

We aren't?

shizzy04• 13 years ago

See http://michaelochurch.wordpress.com/2012/11/18/programmers-d...

diminoten4• 13 years ago

My paycheck begs to differ!

But really, comments are one way to mislead in code. If a comment is made that incorrectly states the intent of code, it's undeniable that this is harmful to the readability of the code.

shizzy04• 13 years ago

What's pay got to do with it? See

http://michaelochurch.wordpress.com/2012/11/18/programmers-d...

Comments may mislead yes, but that's a problem with any sufficiently expressive language, and code is one such language: code can mislead. The functionality required of the code may be only half-implemented, then that code is misleading. That code may work for certain easy cases, but it may be harmful to your understanding of what functionality is actually required.

It's easy to see why we prioritize code over comments, why we prioritize the mechanisms over the specifications. It's because code can have some manner of automatic verification, and we're too harried to look into the comments, to do code review. Deadlines abound. We can't stop work and say, no, we can't do this under these time constraints without sacrificing a minimum level of quality, specifically because we're not treated like an actual profession with the clout or the responsibility that comes with such a thing.

mannykannot4• 13 years ago

I am curious as to how you think this should inform the way we program. You could also say 'coding errors are harmful to the usefulness of programs', but that gives us essentially no insight into how to do things better.

bjackman• 13 years ago

I only started doing this recently. It occurred to me that I had some conception in my subconscious that natural language punctuation wasn't required in formal language code files. I think it may have simply been a cognitive spill-over from the fact that variable names start with lower-case characters.

Looking back, it's totally ridiculous that I would, in a professional setting, put my name next to unpunctuated writing. Aside from being ugly and hard to read, it's straight-up unprofessional.

anigbrowl• 13 years ago

I like detailed comments myself, but this argument is hurt by taking them out of their context - it would have been more instructive to examine different styles of commenting to document a complex function or how they can help or hinder structural understanding.

huhtenberg• 13 years ago

Comments should be meaningful. Whether they are sentences or a Morse code is secondary.

cgrubb3• 13 years ago

As of 2 months ago Ned doesn't follow his own advice:

https://github.com/nedbat/byterun/blob/master/byterun/execfi...

akkartik3• 13 years ago

What're you referring to? They all seem to be complete sentences with capitals and full-stops.

cgrubb3• 13 years ago

Sorry, I didn't think it was hard to find these:

     13     open_source = tokenize.open     # pylint: disable=E1101
     27	# from coverage.py:
     30	    # In Py 2.x, the builtins were in __builtin__
     33	    # In Py 3.x, they're in builtins
     38	    """The same as s.rsplit(sep, 1), but works in 2.3"""
    101	    # Create a module to serve as __main__
    140	        # Restore the old __main__
    143	        # Restore the old argv and path

A reminder of what the blog post tells us:

     Start comments with a capital, have a subject and a
     verb, and end them with a period.

shoo• 13 years ago

http://en.wikipedia.org/wiki/Tu_quoque

cgrubb3• 13 years ago

http://en.wikipedia.org/wiki/Straw_man

sefk• 13 years ago

I love the attention to detail Ned.

akkartik3• 13 years ago

Contrast PG's style, which had a deep influence on me: https://github.com/arclanguage/anarki/blob/master/arc.arc. There's something to be said for an aesthetic of conciseness that lets one spend less time scrolling around and more time just thinking about what's in one's field of view. That includes stripping comments of unnecessary verbiage.

The article does make one good point: that when you add to a terse comment you often have to add capitals and punctuation. But that is also often a signal to me to ask why I need to switch from communicating a fact to creating a narrative. Is the narrative really necessary? Often I find some way to reorganize the code without needing to narrate it. Relevant is http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.htm.... (But I'm not claiming everybody who uses complete sentences is a noob.)

ams6110• 13 years ago

A developer I used to know put it thus: "A comment is an apology." I never asked him to explain that, but I guess he meant it's an apology that the code itself is not self-explanatory.

Clear, even verbose commentary can be helpful. But where it often breaks down is when the code is revisited, and the comments are not updated as well. So my practice now is to use comments in early development to help me remember what I was thinking in that bit of code, but then remove most of them during clean-up and refactoring unless something particularly non-obvious is going on. It makes future maintenance of the code less likely to diverge from the (usually unmaintained) comments.

Good code review could help here: "Hey, the diff shows you changed six lines of code in that function but the comments are the same, do they need to be revised?" But I've never worked anywhere where EVERY commit was reviewed, rather a sampling is selected for weekly review. that leaves a lot of opportunity for things to get missed.

Bottom line: extensive comments can add to workload when fixing bugs or making enhancements. So only use them when they really count.

taeric3• 13 years ago

Meh, I'm a huge fan of "readable code" that is easy to follow and just makes sense with no need for explanations. And then there is code that is non trivial.

Too often I've found that vast amounts of effort were put into keeping something "readable" to the point that all of the extra readable hints either just got too large and unwieldy, or it prevented the developer from picking an easy and straight forward solution. (And to be fair, often that developer was me.)

I think there is a very real divide between what the logical flow for a computer to be presented something and the narrative flow for explaining that to another developer are. And no amount of clever variable/function names will really help here.

In fact, often times it can be worse. The proverbial isle of a grocery store. Too much to look at with no obvious "main" method. There is a reason it is a "rookie mistake" to have giant methods that do too much. When it comes down to it many people were only trying to get their program to do one thing. Cluttering their memory with the myriad steps necessary to get there is a large hurdle to get back into something.

tsiki• 13 years ago

The programmer who doesn't change the documentation when changing the code is usually the same one who doesn't change the function name when changing its functionality. If a bad programmer is tweaking your code, it doesn't really matter if the documentation is in the variable names or in the comments.

grantph• 13 years ago

I usually start by writing comments first in plain English based on a variation of psuedocode. That way I'm focused on process first without distraction. Comments are the plan. Clearly articulated steps like any good cookbook. Easy to translate into any language.

// 1. Write plain English psuedocode.

// 2. Translate into scary looking code blocks.

// 3. If maintaining, remember to update comments first (goto Step 1, then Step 2).

The irony is another developer once claimed that my code was generated by a machine. Apparently it was too methodical to be human. Like that was some excuse for him to write crappy code. Urgh! To be great at anything, you need to have excellent communication skills!

Comments should be sentences

Related Stories