Beefy Boxes and Bandwidth Generously Provided by pair Networks
Keep It Simple, Stupid
 
PerlMonks  

Re: Why no comments?

by gone2015 (Deacon)
on Feb 01, 2009 at 02:00 UTC ( [id://740494]=note: print w/replies, xml ) Need Help??


in reply to Why no comments?

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

Comments should be regarded as an integral part of programming, at least as important as the data and the code. Comments should cover the purpose and meaning of both data and code -- information that doesn't come from reading the code, which can tell you what it is doing, but not why and to what end.

The key to designing good data structures and good code is a clear understanding of their purpose and the objectives. It is good discipline to include comments which describe that much. It is excellent discipline to write those comments, at least in draft form, before defining the data or writing the code -- and then refine data, code and comments together. If it's hard to express the purpose of the data or code, what hope is there of being able to implement it effectively ?

Each subroutine should be commented so that you know what the arguments and return values are and mean, without reading all the code, and looking at everything it calls. You should not have to read all the code to reverse engineer an understanding of what data structures mean and are used for.

Each data structure, each module and each object should contain comments to describe their meaning and purpose. Comments should also cover any key dependencies, assumptions, limitations, caveats, key algorithms, obscure or key background information, etc.

Good commenting can:

  • make you describe what is intended. This helps clarify the problem before coding. It also reminds you, three months from now, what you thought you were doing.

    As you review the code and its associated commentary, it can become obvious that there's a mismatch between what was intended and what's been written. During debugging, the commentary can remind you what was intended... so you don't just assume that what it does is right !

  • make you to consider edge conditions and check that cases that need to be covered are covered. You should do that anyway, of course, but if you write it down it's more concrete.

  • require you to express and examine assumptions.

  • justify and document the choice of algorithm or method.

  • leave notes on things which were not obvious when you worked out what needed to be done or how to do it -- so you don't need to rediscover this in six months time.

  • and so on.

The writing of good comments is not a distraction or an overhead. It should reflect what the programmer must think about in any case -- the discipline of writing it down concentrates the mind, and contributes to the quality of the code. Later on, in maintenance and upgrade, good comments speed up the process of understanding.

I am filled with wonder and admiration for people who can churn out reams of self-documenting code, without having to work out and write down what it is they are doing and why ! Mind you, I prefer to admire them from a (very) great distance.

Replies are listed 'Best First'.
Re^2: Why no comments?
by BrowserUk (Patriarch) on Feb 01, 2009 at 04:08 UTC

    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.

      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.
Re^2: Why no comments?
by shmem (Chancellor) on Feb 01, 2009 at 23:29 UTC
    Good commenting can:

    What about s/Good commenting can:/Good coding can:/ ? And that's the main point.

    • make you describe what is intended.

      That can, and should be done with code proper.

    • make you to consider edge conditions and check that cases that need to be covered are covered. You should do that anyway, of course, but if you write it down it's more concrete.

      What is better than code which considers edge conditions, naming the conditions by proper set branches and variables? The requirements are (or should be) in the specs. Code is no place for that.

    • require you to express and examine assumptions

      that is what we do all time along coding perl. Anything which can't be done that way needs to be cleared beforehand and laid down in the specs.

    • justify and document the choice of algorithm or method.

      The choice of algorithm is done per knowledge. Now, you wouldn't document your knowledge in any (every?) piece of code you write, would you? Algorithms can be named, if they have a name. If they work out to the specs, that's fine. If they don't, they are changed, and describing the "why and whence and how" sayings doesn't add anything to the comprehensiveness of the code. The code should be written to be comprehensive in the first place.

    • leave notes on things which were not obvious when you worked out what needed to be done or how to do it

      This is the only reasonable item in the list - quoting Kernighan: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."

      Teaching perl, the first code samples of your pupils are like that:
      open my $h, '>', $file # try to open a file or die "Can't open '$file' for writing: $!\n"; # if that fails, te +rminate with a message while(<$fh>) { # reading a line via <$fh> assigns per default +to $_ s/foo/bar/; # s/// operates per default on $_ }
      That's okay, since they want to remember what they have learned. Maintaining code and refactoring is a totally different issue. If you do that, you have to toss around code, and having comments piggyback is - piggyback, and a burden. If every EXPR is written properly; if every STATEMENT is clearly written; if every BLOCK defining a SCOPE containing STATEMENTS which are comprehensible on their own, or as part of the enclosing PACKAGE, or APPLICATION to which they apply, everything is fine.

    I choose to code in perl (also ;-) because that way I have a wealth of expressions at hand which makes - or could make, if I work up to my level of experience - the code self-explanatory. And that's the goal. Anything below that can only be badly mended with comments. They are workarounds. Your program is a technical paper, which should be readable on its own by technicians of the same craft, but not necessarily for pupils (unless you are a teacher) or laymen. Those technicians which can't need teaching (by themselves, or training by somebody else), and that fact cannot be mended with comments either.

Re^2: Why no comments?
by talexb (Chancellor) on Feb 01, 2009 at 21:21 UTC

    I'm surprised to see this node has a negative reputation -- I don't disagree strongly enough with it to downvote it, but I think it sets the 'you must comment!' bar a little high.

    I agree that code/comment mis-matches is a problem -- in that case, I'd rather have no comments than bad comments.

    Writing down comments on edge cases doesn't make the code more concrete -- comments don't change the code.

    And I disagree that .. the writing of good comments is not a distraction or an overhead; if the comments get written during development, that's fine. Having to go back and add the comments afterwards is definitely overhead. Sometimes there just isn't time to spend a leisurely week adding comments and generally tightening code up.

    Pull out some code from CPAN (say) and critique it for us .. we'll be glad to give you some feedback. :)

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      Writing down comments on edge cases doesn't make the code more concrete -- comments don't change the code.

      Ah, what I was trying to say was that the writing of the comment helps make the thinking more concrete: often I can think I have something clear in my mind, but when I have to write it down, I find that my thinking was sloppier than I thought... if you see what I mean.

      if the comments get written during development, that's fine.

      Absolutely. This is what I was trying to say when talking about the comments being an integral part of the programming process. You have to think a chunk of code (or data) is for before you write it... writing some of that down in the form of comment helps the thought process now, as well as having benefits later.

      The writing of comments also has its place when reviewing the code. First, again because the act of writing concentrates the mind. Second, if the code and the comments don't tally, something needs to be thought about !

      I must say I'm taken aback by the response... I get the feeling that there are a number of people who've been traumatised by being forced to eat their greens. Suggesting that greens should form part of a balanced diet seems to produce a gagging response :-)

Re^2: Why no comments?
by rir (Vicar) on Feb 02, 2009 at 22:06 UTC
    I do believe that light commenting is good.

    In your bullets, you make the following points:

    1. helps clarify the problem before coding

      Yes, but sometimes these notes should be kept separate as design documentation. Some of this can also be done by writing tests.

      Here you are saying they have served their purpose already; you need another purpose to shove them into the code.

    2. reminds you ... what you thought you were doing.

      This is true, but it is could also true of the code itself. This can also be done with tests.

    3. [make] obvious that there's a mismatch between what was intended and what's been written

      No, this is like having two compasses that don't agree. Well, if you're the author, it can work until tickling your memory doesn't help.

      Expressing your intentions for some code can be more precisely done by tests.

    4. make you to consider edge conditions and check [them]

      Better done by testing.

    5. require you to express and examine assumptions.

      Better done by testing.

    6. justify and document the choice of algorithm or method.

      Agreed.

    7. leave notes on things which were not obvious when you worked out what needed to be done or how to do it

      What is being done and how it is being done is captured in the code; the mindset of a maintainer with the artifact of the code before him may not mirror that of the writer who sat down with no code in front of him.

    8. and so on.

      May your comments not be so vague, :-) and testing will probably help with whatever this is :-).

    Be well,
    rir

Log In?
Username:
Password:

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

How do I use this?Last hourOther CB clients
Other Users?
Others sharing their wisdom with the Monastery: (6)
As of 2024-03-28 08:32 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found