targetsmart has asked for the wisdom of the Perl Monks concerning the following question:
The reason for asking this question is, as and when I use a subroutine from an external module(can be core module or downloaded from CPAN), I would go and see how the subroutine was implemented in the code by the author, to get to know the good/efficient practices, but many a times because of lack of comments I have gone to other modes like using a debugger, copying only that subroutine and putting some debug messages to it, etc. It would be excellent if it comes with sufficient comments(from a learner point of view).
I believe that I have asked nothing wrong here.
Vivek
-- In accordance with the prarabdha of each, the One whose function it is to ordain makes each to act. What will not happen will never happen, whatever effort one may put forth. And what will happen will not fail to happen, however much one may seek to prevent it. This is certain. The part of wisdom therefore is to stay quiet.
|
---|
Replies are listed 'Best First'. | |
---|---|
Re: Why no comments?
by GrandFather (Saint) on Jan 31, 2009 at 11:02 UTC | |
Writing good comments is at least as hard as writing good code. Bad comments can be worse than bad code. Comments can give the reader the impression that they understand the code without the need to actually read and understand the code. If the comments are good, that's fine. If the comments are bad that can lead to a great deal of wasted time and frustration. Don't get me wrong. Comments are an important part of writing good code. But it is better to write good code that speaks for itself than to write a translation of the code into some semblance of English (or whatever language is appropriate). Good comments convey the intent of code and may explain how a tricky algorithm works, but doesn't give a blow by blow description of the code. Modules provided by CPAN are written by people of vastly varying ability and can demonstrate code on many different levels, but few of those modules are written for their educative value. "Dumbing down" a module so that it is accessible to learners doesn't help CPAN and doesn't actually help learners. For one thing, there are much better ways to learn Perl basics (PerlMonks for a start), and for another: learners don't stay learners for ever, so what level should the comments and code be aimed at? Comments in code for CPAN should be designed to ease the job of maintenance programmers. Generally that means few comments and much thought given to appropriate coding, identifiers, documentation and test suites. That is not to say either that there isn't a lot to be learned from reading CPAN code. There is a great deal that can be learned from examining CPAN code. But you shouldn't expect it to be entry level stuff. Perl's payment curve coincides with its learning curve. | [reply] |
by doom (Deacon) on Feb 01, 2009 at 21:54 UTC | |
If the comments are bad that can lead to a great deal of wasted time and frustration.This is a very common attitude, and I suppose it must reflect someone's experience, but it doesn't reflect mine. My experience is that even when the comment is in error it gives you a hint about the history of the code, the state of mind of the author, and so on. It's a basic skill of reading, if you ask me: you can't take anything at face value, but it doesn't mean it's worthless, either. | [reply] |
by moritz (Cardinal) on Feb 01, 2009 at 22:49 UTC | |
you can't take anything at face value That statement is not true about code. If you compiler isn't buggy, the code does exactly what it says it does. And it's the whole reason why code is more important than comments. | [reply] |
by GrandFather (Saint) on Feb 01, 2009 at 22:07 UTC | |
During bug fixing some time ago I came across a comment that was plain wrong - it described the effect of the code as being the opposite of the actual effect. After spending considerable time "fixing" the code I discovered that it had in fact been correct and that the bug I was looking for was in a completely unrelated piece of code. In that particular case there was no need for the comment. One reason the code took considerable time to "fix" was that all the identifiers were "wrong". Without the comment the code was correct, consistent and clear. However, the comment was plausible and in the context of the symptoms of the bug the code could well have been incorrect. Perl's payment curve coincides with its learning curve. | [reply] |
Re: Why no comments?
by shmem (Chancellor) on Jan 31, 2009 at 11:29 UTC | |
Comments in code are for maintainers. They point out parts which need fixing, lay out assertions on which the current piece of code relies, explain unusual constructs and point out side-effects upon other parts far away. Sometimes they refer to a bug ticket. A maintainer has the skills to understand the code without third party help, and comments which explain the code further than that are annoying and obscuring the fact to her. All other comments on the code live in the documentation, and in the skill of teachers. See also the thread An Introduction to Literate Programming with perlWEB which also discusses the use of comments. | [reply] |
Re: Why no comments?
by roboticus (Chancellor) on Jan 31, 2009 at 14:40 UTC | |
Your code should be written to be as clear as possible, as it's supposed to adequately explain *what* it does. Normally, the types of comments I use are:
Of course, commenting styles are varied, so this list is strictly my opinion... ...roboticus | [reply] |
Re: Why no comments?
by sundialsvc4 (Abbot) on Jan 31, 2009 at 16:56 UTC | |
(Shrug...) “It could be better. It could always be better.” I suggest that you might contact the owner of the module in question (privately...) and offer some clarified text and where you'd like to place it. Maybe you could become one of the credited maintainers of the module. Maybe your entreaties would be rebuffed, but maybe (likely...) they would be warmly appreciated. After all, as we all know, it's tough to look at your own work from somebody else's eyes; to know what will and will not be clear, or useful, to someone else. Tread delicately. There are human egos nearby. Don't name names here; start with private contact. | |
Re: Why no comments?
by ELISHEVA (Prior) on Feb 01, 2009 at 08:57 UTC | |
Consider a block of code consisting of a while loop with internal variables named $high, $low, $mid. I think most experienced programmers skimming the code would assume that the loop is some kind of binary search algorithm. They might appreciate (at most) a very short comment saying #binary search right above the start of the while loop, but anything more than that would be annoying. On the other hand, if there was something weird about the use of a binary search in that context or it really wasn't a binary search, then any of the following comments might be appreciated: But each of those comments requires a great deal of context and experience even to construct. A programmer who doesn't know what a binary search algorithm looks like is hardly going to know that he or she needs to comment their code when it looks like one but isn't. On the other hand, I'm sure some of us can remember when we were first learning the ideas behind a binary search. Grasping each step of the algorithm was painful and we very much appreciated our professor or text book explaining each step of the algorithm and why it was done that way. As a further thought, what does and doesn't need to be commented changes over time even for the software industry as a whole. Before the discussion of patterns became widespread, it would have been impossible to comment code using a visitor pattern with a one liner #process foo using visitor pattern. Best, beth | [reply] [d/l] [select] |
Re: Why no comments?
by toolic (Bishop) on Jan 31, 2009 at 17:09 UTC | |
How much did you pay for the modules you are using, or will use? My guess is "zero". It is my understanding that most (if not all) of CPAN modules are created by volunteers. Perhaps many authors (such as myself) spent nights and weekends away from work writing tests and POD -- without monetary compensation. There is no army of well-paid Micro$soft hackers churning out CPAN modules on the company's dime. Maybe you get what you pay for :) Do you know of any other free software repository in which most of its library components have ample/accurate/coherent comments? Please provide some links. most of the CPAN/core modules lacks commentsThat is an amazing claim, considering there are more than 10,000 modules on CPAN. | [reply] |
by DrHyde (Prior) on Feb 03, 2009 at 11:05 UTC | |
If anyone were to submit a patch for my free code consisting solely of comments, I would at least consider applying it - after checking that the comments were correct and meet my arbitrary definition of useful. Similarly, I accept doco patches. Comments are really just a type of doco anyway - they're documentation for the maintainer. | [reply] |
Re: Why no comments?
by tilly (Archbishop) on Feb 01, 2009 at 00:50 UTC | |
I still stand by what I said then. If you wish more enlightenment, I highly recommend picking up a copy of Code Complete and reading it cover to cover. Yes, it is long. Yes, it is detailed. However every last bit of it is highly worthwhile to read, think about, and try to understand. | [reply] |
Re: Why no comments?
by zerohero (Monk) on Jan 31, 2009 at 23:47 UTC | |
Internal comments are for maintainers, not for people using the code. Since good/efficient practices is a huge issue, and subject to many larger factors, it makes no sense to embed this kind of general comments in code. | [reply] |
Re: Why no comments?
by gone2015 (Deacon) on Feb 01, 2009 at 02:00 UTC | |
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: 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. | [reply] |
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 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.
| [reply] |
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. | [reply] [d/l] [select] |
by BrowserUk (Patriarch) on Feb 01, 2009 at 23:24 UTC | |
by gone2015 (Deacon) on Feb 02, 2009 at 15:16 UTC | |
| |
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. 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. | [reply] [d/l] [select] |
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. :) | [reply] |
by gone2015 (Deacon) on Feb 02, 2009 at 11:34 UTC | |
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 :-) | [reply] |
by rir (Vicar) on Feb 02, 2009 at 22:06 UTC | |
In your bullets, you make the following points:
Be well, | [reply] |