http://www.perlmonks.org?node_id=740502


in reply to Re: Why no comments?
in thread Why no comments?

I've downvoted this post. Not because it flies in the face of everything that I've come to believe over a long (and I believe deeply thoughtful and curious) career--though it does.

But because, as with so many of these theses, it attempts to argue and convince, not on the basis of strong pro-logic, nor strong counter-argument to the opposing views. But rather on the basis of: commenting is so obviously good, that not commenting can *only* be the product of laziness and indifference; which is absolutely not the case for many of us that prefer minimal commenting.

I started my professional coding in assembler, and commenting every line. And every routine started with big, gaudy block comments detailing date, time, author, revisions and reasons, inputs, outputs, side effects, purpose, methods and references et al. Through Bliss, Fortran and C and several others, the level of commenting slowly reduced. Not because I was too lazy to comment, but because as I went back to maintain code--my own and others--I found that the comments were inaccurate, unhelpful or misleading. And sometimes all three.

Comments made by the original authors--including myself--no longer made sense in the light of

  1. The new purpose to which the routine was being put.
  2. My new level of understanding of the purpose of the routine in the calling code, or my better understanding of the problem the code is to address in the light of the bugs that it accumulated in use.
  3. The fading of the memory (or no knowledge at all of it), of the mindset of the author when the code was written.

In a nutshell: things that seemed important to the author when writing the particular line, block or subroutine, are no longer significant once the intensity of thought about those lines is no longer fresh in your mind and you are instead caught up in the malaise of the bigger picture. Comments that made sense in the light of a library routine's place in one project, no longer have any significance when that library is re-used in another.

You make some claims for the advantages of "good commenting". So, I raise you a challenge. Show us an example! And let us pick over its bones. It could be very enlightening.


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

Replies are listed 'Best First'.
Re^3: Why no comments?
by gone2015 (Deacon) on Feb 01, 2009 at 21:28 UTC

    You seem to have taken particular exception because you think I made no real case, but argued:

    ... on the basis of: commenting is so obviously good, that not commenting can *only* be the product of laziness and indifference; which is absolutely not the case for many of us that prefer minimal commenting.

    Well... what I thought I'd done was to describe in broad terms what I consider to be the attributes of good commenting, and then to enumerate what I think are some of the benefits. I fail to see how that is starting from a position of "commenting is so obviously good", far less jump from there to an accusation of "laziness and indifference". I feel you've misrepresented what I said... but, hey ho, it's an imperfect world.

    I agree that there is such a thing as excessive and pointless commenting -- which is made-work both for the original author and for later modifiers. In my assembler days I would despair of programmers who thought that every instruction required a comment saying what it was.

    I'm not sure whether you are arguing for no comments at all, or whether the question is the degree and type of comments ? If the second, then I'd be interested to hear what you think represents "good" commentary.

    However, you asked for an example. OK. I posted this some time ago. I haven't constructed it as a text book example of good commenting -- in any case, like most forms of writing the question is: "who is the audience ?". Alternatively, I can offer ensure.pm. I look forward to seeing them torn to shreds :-) [Looking back at the posting, there is quite a bit of background -- if you just want to look at the module, see here.]


    I will also give an example of where, IMO, there is a shortage of comments. This is from numeric.c in the Perl 5.10.0 source.

      what I thought I'd done was to describe in broad terms what I consider to be the attributes of good commenting,

      Your opening line is:

      "It is indeed a sad state of affairs when programmers fail to properly comment as they write code."

      And that sets the tone for the entire post.

      For the rest. When I encounter modules that contain that much verbiage I often just delete it without reading it.

      Especially when I encounter comments like

      # Reverse sort the set and partitions and insert sums

      To "document":

      @$rs = reverse sort numerically @$rs ; @a = ($sa, reverse sort numerically @a) ; @b = ($sb, reverse sort numerically @b) ;
      • Reverse: This keyword precedes all three sorts.

        It is redundant.

      • sort: as is this.
      • the set: if @$rs was @$set, this word becomes redundant.
      • and partitons: Ditto these, if @a and @b where @partA and @partB.

        Especially if the sub were called partitionShuffled() rather than hack_C.

      • And insert sums: Ditto if $sa and $sb where $sumA & $sumB.

      Three lines of verbiage (including 2 blanks) mostly redundant. And completely redundant if the documentation is placed in the only verifiable content of the file--the code.

      And

      # Done -- return partitins in required order

      to "document"

      if ($a[0] >= $b[0]) { return (\@a, \@b) ; } else { return (\@b, \@a) ; } ; } ;
      • Done --: The end of the subroutine and your done. No shit Sherlock!
      • return: And your going to return something. Cool.

        The fact that you use return in the code (twice) is a pretty clear clue.

      • partitins: @partA & partB would be so much better.
      • in required order: Required for what? By whom?

        You mean partition A then partition B if the sum of A is greater or equal to the sum of B. Or vice versa otherwise.

      • (And what's with that floating semicolon after the subroutine?)

      Again, mostly redundant, with the code being far clearer than the "documentation".

      And the whole lot would be clearer still (and far more efficient to boot), written as:

      # Sort the callers array in-place @$set = sort{ $b<=>$a } @$set; return $sumA >= $sumB ? ([ $sumA, sort{ $b<=>$a } @partA ], [ $sumB, sort{ $b<=>$a } + @partB ]) : ([ $sumB, sort{ $b<=>$a } @partB ], [ $sumA, sort{ $b<=>$a } + @partA ]) ; }

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

        Thanks for the comments.

        It appears there is little common ground on which to base a discussion, but since you picked out two examples, I'll address those briefly, and then not waste any more of the monks' time.

        For me, the writing of comments is part of the thinking process. The comments you commented on were (if memory serves) written before the code, as I was sketching out what needed to be done. I agree that comments that do no more than repeat what the code says are not only redundant, but can simply be clutter (except where the code is particularly tricky) -- for me the key is to concentrate on the "why". Though I do find it useful to use comments to point up the stages that a block of code goes through.

        The first comment you picked out:

        # Reverse sort the set and partitions and insert sums
        served several purposes: (a) it was a stage in the subroutine; (b) the algorithm used depends on stuff being reverse sorted, this is key to understanding what is going on; (c) it's doing something a little tricky: in the resulting array entry 0 is not the same as the other entries, it's the sum of those entries. While I was writing it, I thought about all this... I suppose I could have written a longer comment to emphasise the key points...

        The other comment you picked out:

        # Done -- return partitins in required order
        (sorry about the spellin error)... well, yes, it's not the most significant of the comments in a 2,800-odd line module. Again, the subroutine was broken into stages, so this also serves as the end of the previous stage. The order in which the partitions are returned is key -- the caller can (and does) depend on this.

        As it happens, there are three similar subroutines, with the same general shape, and the comments emphasise that. You've commented on the smallest of the three, where there is less to comment on.