Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Re^3: Why no comments?

by gone2015 (Deacon)
on Feb 01, 2009 at 21:28 UTC ( #740582=note: print w/replies, xml ) Need Help??


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

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.

I looked at this source to discover why Perl decimal to binary conversion is not correctly rounded. To cut a long story short, Perl_my_atof2() is a home-brew conversion routine, which makes a mess of some cases.

I wondered why the code doesn't use atof(), and therefore depend on the library writer's skill. There is no commentary to help. I understand, from responses to the bug report I submitted, that the code used to use atof() until its semantics changed in C99 ! Quite a lot of work went into Perl_my_atof2() -- I would have commented on why, at least.

The solution to the problem is to discard all the arithmetic in Perl_my_atof2() and replace it by something which checks that the incoming decimal number string is a valid Perl number, and feed the (possibly modified) string to the real atof(). I would happily bang out a patch to do that... except that it's struggle to work out what the code is expected to do, because there isn't anything at all to say why it is the way it is.

The issue is complicated by the problem of Locale. This is the code that uses Perl_my_atof2() -- I promise you, I have not removed any comments !

NV Perl_my_atof(pTHX_ const char* s) { NV x = 0.0; #ifdef USE_LOCALE_NUMERIC dVAR; if (PL_numeric_local && IN_LOCALE) { NV y; /* Scan the number twice; once using locale and once without +; * choose the larger result (in absolute value). */ Perl_atof2(s, x); SET_NUMERIC_STANDARD(); Perl_atof2(s, y); SET_NUMERIC_LOCAL(); if ((y < 0.0 && y < x) || (y > 0.0 && y > x)) return y; } else Perl_atof2(s, x); #else Perl_atof2(s, x); #endif return x; }
For me there are two issues here:

  1. the key question is, why does it do Perl_my_atof2() twice ?

    Perl_my_atof2() is not a cheap operation. Who knows what it costs to switch the numeric locale. So it looks as though there must be some important semantic requirement here. I would have thought that merited some comment ?

    Suppose Perl_my_atof is given the string '123,456.789' -- if the locale has a ',' decimal point, then the answer is 123point456, otherwise it's 123 (duh). I'm missing something, I expect, but I cannot see why two passes are required or what problem it is supposed to solve. The author must have had to think this through... it would not have cost much to leave some notes for posterity ?

    Perl_my_atof2() itself worries about locale, and will (as far as I can see) accept either the current locale decimal point or '.'. I have a feeling that this means that the two passes in Perl_my_atof() are unnecessary -- if only I could be sure what they were for. If so:

    • I observe that there is no commentary to describe the acceptable form of numbers, so perhaps whoever wrote the two passes didn't fully understand what Perl_my_atof2() does ?

    • or, perhaps more likely, the two passes in Perl_my_atof() were required before Perl_my_atof2() was introduced, but whoever wrote Perl_my_atof2() couldn't see why either, and hence couldn't see that its locale handling is either redundant or makes the two passes redundant.

    A relatively small amount of "why" commentary would help a lot now. Who knows, a little bit of more general commentary might have helped in the past.

  2. sadly, the comment there is, is useless -- it tells you no more than what the code tells you.

Obviously I could settle down and run some test cases, and reverse engineer the requirements. As it happens, I'm not that familiar with the effects of locale switching, which adds to the problem. Just a few comments would do to equip me with the information required to fix the bug...

...further, if I'm right about the two passes in Perl_my_atof being redundant -- a few comments might have helped others too !

Replies are listed 'Best First'.
Re^4: Why no comments?
by BrowserUk (Pope) on Feb 01, 2009 at 23:24 UTC
    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.

        For me, the writing of comments is part of the thinking process.

        In effect, you are using prose as a form of pseudo-code.

        In the past I've tried or used prose, Weiner-Orr Diagrams, Yourdan, SSADM (and derivitives), Jackson, UML, various flavours of Case, and half a dozen variants of pseudo-code to plan code and/or document it. Some with more or less success than others. But in the end, I've found that the language of implemetation is the best pseudo-code (for me!).

        I'll often start by sketching out the skeleton of the algorithm in Perl-glish (or C-glish or whatever-glish), and then slowly refine that into code. The advantage is that even at the early stages, I can use the compiler or interpreter to check my progress. When the compiler stops complaining, I'm usually getting close.

        it's not the most significant of the comments in a 2,800-odd line module.

        Agreed. And it is perhaps a little unfair to pick out so few lines from so many, but to do more entails a lot of work. I did make a start on attempting to re-write the entire module in what I would consider to be a self-documenting style, but then realised it would be equally unfair, as I would be starting from the position of your working example. I also ran out of awake cycles.

        The bottom line has to be that there is no 'one right way' to program. But historically, I've found that people tend to be even worse at writing good comments than they are at writing good code. The difference is that I have the compiler to help me sort out the code, but no assistance is available for comments. (Especially a problem for me if they are in German or Italian or Chinese or Spanglish :)

        I've personally found it more efficient and effective to put a little more effort into chosing variable and function names that allow the code to be somewhat self-documenting, than to write everything twice. But I realise that that doesn't do it for everyone.

        But I do take exception to the implication that my deliberate and considered preference for minimal commenting is born of laziness or a lack of consideration; as nothing could be further from the truth.


        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.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://740582]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (8)
As of 2019-10-22 01:58 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?