Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re:{2} Commenting, was: Inline POD vs. EOF POD

by jeroenes (Priest)
on Jul 10, 2001 at 13:22 UTC ( #95261=note: print w/ replies, xml ) Need Help??


in reply to Re: Inline POD vs. EOF POD
in thread Inline POD vs. EOF POD

I use block comments to explain the implementation, and POD to explain the usuage. And IMO, if you use only POD, you either have lousy manual pages, or your code is very lousy documented.
On several occasions a monk who we all think highly of, let me know that good code comments itself. If you choose the names of variables and functions carefully, their function in the program becomes clear without separate comments. Comments appear to have the tendency to get out of sink with the code after some reviewing/ debugging rounds. So if you don't need comments at all, your code is better in the long run. I won't claim that I can write such code although I try, and I still feel more comfortable with comments all over the place.

This of course has nothing to do with inline/EOF POD. I see the general case for EOF PODs, but I can think of modules where inline PODs come more natural. If the module only exports a series of reasonable independent functions (so no OO), the interface-PODs can perfectly stay with the exported functions. But even than general usage and example docs are probably better situated EOF.

Jeroen
"We are not alone"(FZ)


Comment on Re:{2} Commenting, was: Inline POD vs. EOF POD
Re: Commenting, was: Inline POD vs. EOF POD
by Abigail (Deacon) on Jul 10, 2001 at 19:45 UTC
    On several occasions a monk who we all think highly of, let me know that good code comments itself. If you choose the names of variables and functions carefully, their function in the program becomes clear without separate comments.

    Yeah, I've heard that before too. K&P write that too. And it's certainly true that well written code needs less comments. It avoids micro comments, of the style "add one to the number of elements". However, in general well choosen names of variables don't explain *why* certain actions are taken. At best they tell us what is going on. And usually, they don't tell enough of the global picture, an entire block or function. Names alone don't tell us why statements have to be done in a certain order - they don't show pre- or post conditions.

    I know only one program of substantial size that's commented only sparsely, and that's perl. But I've never heard that code is easy to grasp...

    -- Abigail

      I'm not going to say that the perl source is a good example!

      You can use naming conventions to include the actions related to vars/functions. Like translate_buffer_to_normalized_image. Well, names get pretty long but are self-explaining. And such names can give info about pre/post conditions...

        translate_buffer_to_normalized_image might sound as it's a self-explaining variable name that doesn't need documenting, but is it really that practical? Too long variable names don't "stick". And long variable names make that expressions need more than one line, making programs harder to understand.

        As for names having info about pre/post conditions, could you give a convincing example? I do have a hard time believing you.

        -- Abigail

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others wandering the Monastery: (5)
As of 2014-09-22 21:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (203 votes), past polls