Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Re: Commenting, was: Inline POD vs. EOF POD

by Abigail (Deacon)
on Jul 10, 2001 at 19:45 UTC ( #95335=note: print w/replies, xml ) Need Help??

in reply to Re:{2} Commenting, was: Inline POD vs. EOF POD
in thread Inline POD vs. EOF POD

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

  • Comment on Re: Commenting, was: Inline POD vs. EOF POD

Replies are listed 'Best First'.
Re:{2} Commenting, was: Inline POD vs. EOF POD
by jeroenes (Priest) on Jul 10, 2001 at 20:30 UTC
    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

        I ment that translate-name to be a function, as it has a verb and should do something, rather than be something.

        About the length of the names and code-lines. How understandible a block of code is does not really relate to the length of expressions, but also to the formatting and the names. If the names are well-chosen but long, the formatting should be clear. Together with the way the program is broken up in functions, that determines the accesibility of some code, not whether expressions fit in one line or not.

        For example, nested or sequential maps are a pain to read when put on a single line. Spread out over several lines the code often becomes clear. And we are talking about expressions with very short names. In this example it doesn't really matter whether your names are 10 or 30 characters, the code still gobbles up the same number of lines.

        From another point of view, lines with more than say three or four variable names are probably hard to read anyway. Spreading it out over multiple lines can help than.

        When browsing code like some linux kernel or whatever GPL program I need to tweak a bit to compile, I encounter C consisting of lots of comments intertwingled with short code. (And I wouldn't dare to claim that those are really well written examples) I find these things hard to read as well. The flow of logic in the comments is done by the authors, and is not the programming logic. There already is enough freedom in how to write code, the different ways to comment make code in general harder to read. I'd rather have to code spanning somewhat more lines than having those flexible comments in the way.....

        About pre/post conditions. Tough topic, when I think of it. A condition is a circumstance before/during/after a function. I would say that such beasts belong to the interface anyway. They can or should be named in the function-name, or be explicitly mentioned in the parameter lists. Let us for example consider code that retrieves some user-information, and count the ocurrence of a 'p'. Pretty useless of course. Depending on a condition (eg are we running under windowz?) the list has to be pulled from the builtin functions or from an user file:

        if ( $^O =~ /win32/) { get_userinfo_by_id_from_txtfile( $userid ); } else { get_userinfo_by_id_from_perlfunction( $userid ); } my $p_count_in_userinfo = count_p_in_array; report_p_count_at_interface( $p_count_in_userinfo, $reporting_interfac +e);
        Depending on the remainder of the program, these interface choices may be a Good or a Bad idea. If we bury the win32 condition a bit further in the interface, which may well be a Good Thing for programs in general:
        get_userinfo( $userid ); my $p_count_in_userinfo = count_p_in_array; report_p_count_at_interface( $p_count_in_userinfo, $reporting_interfac +e); sub get_userinfo{ my $userid = shift; my $is_this_gnix = get_gnixiness_system; get_userinfo_on_system( $userid, $is_this_gnix ); }
        This can be extended forever, I think the idea is clear by now. With this naming convention, the conditions automatically get into the naming of functions and variables.

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others imbibing at the Monastery: (5)
As of 2021-04-13 01:10 GMT
Find Nodes?
    Voting Booth?

    No recent polls found