saberworks has asked for the wisdom of the Perl Monks concerning the following question:

Just got my copy of Perl Best Practices and I'm trying to figure out the author's "rule" for subroutine parameter passing. If it's spelled out somewhere, I can't find it, so please point me at the correct page and I'll leave you alone.

If not, here is the source of my confusion. On page 12 there is a bolded code example: my @candidates = get_candidates($marker); Which leads me to believe he doesn't want spaces after or before the parens. For example, he likes the above better than: my @candidates = get_candidates( $marker ); However, on page 13, there are lines like this: 
chomp( $record );
my ($name, $votes) = split("\t", $record);
substr($name, 0, 10);

[download]
So the "rule" appears to be: "If it's a built-in, don't add spaces, except if there's only one argument, then do add spaces. If it's user-defined, don't add spaces, even if there is only one argument." Except, then I found one on page 29 that was even worse: add_step( \@steps, $next_step, $elapsed_time);

I also find it disconcerting that the author advocates putting spaces for "complex" hash keys, like $foo = $var{ $names{$i} }, but not for code blocks in things like grep and map: grep {defined $_} @something; (and actually on page 17 I see map { sqrt $_ } @results; so maybe this is just an accidental inconsistency).

So maybe I'm being picky, but my company is now trying to identify a coding standard for all our programmers to use, and at the beginning of the chapter I was hoping I could just point to this and say, "we should use this, it's clearly documented, there's reasoning behind each recommendation, and other good perl programmers coming on board will have a high liklihood of being previously exposed to it."

Am I looking at typos which will be fixed in the next version of the book or is this issue something that's generally not explicitly defined in most coding standards?

Replies are listed 'Best First'.
Re: PBP: Code Layout
by BrowserUk (Patriarch) on Oct 19, 2005 at 22:39 UTC

    Like most people, I have my own preferences for code layout. I tend to use more horizintal whitespace and less vertical than other people.

    But the single most important rule in my book is:

    Above all, be consistent!
    .

    Personally, I'm gonna code new code, my way. This less through beligerance than the simple fact that having to stop and think about style, rather than letting it flow naturally, imposes too high a price in terms of distraction from the task of programming.

    If client rules absolutely insist, I'll use a code beautifier to re-format my code to the "house style" when I'm done with it, or at checkin. With most code editors it is fairly easy to set up macros to run the beautifier to house rules and then do check in and to my preference on checkout.

    That said, when I pick up someone elses code, if I am only browsing or making a simple change, then I'll skip the reformating, if they have a consistant style. It is generally fairly easy to aquire a good eye for whatever style is used, if it is used consistantly.

    If they don't, and/or I need to get a good understanding of their code, I'll more often than not reformat their code by hand, line by line, from the top to bottom. I find that the process of going through the code doing this forces me to actually read each line rather than just scanning it.

    Reading and familiarising yourself with a piece of code, even a piece of your own from a few months ago is the single best way of avoiding making silly mistakes. It only takes a few minutes to do and saves so much time in the long run.

    Generally, I am pretty skeptical of the "simple code avoids maintenance problems" argument. Personally, it is rarely making changes to moderately complex code where I make silly mistakes. It is the quick, "obvious" changes to simple code, where the mistakes creep in.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    The "good enough" maybe good enough for the now, and perfection maybe unobtainable, but that should not preclude us from striving for perfection, when time, circumstance or desire allow.
[reply]
Re: PBP: Code Layout
by Skeeve (Parson) on Oct 19, 2005 at 22:03 UTC

    I can't say anything about that book or about "good style". I just can say: I don't want to be forced by whatever policy to use a certain code style. To me it's nonsense. Simply a waste of time concentrating on formatting the code instead of developing it. It's something that should be done by a program not by a programmer.

    When I learned Pascal at university back in 1984 or so, we had to follow a certain style. Do you think anyone followed the rule of UPPERCASING all keywords?

    NO ONE! Everyone wrote his one "keyword-uppercaser". Everyone immediately noticed, that focussing on formating is a waste of time.

    s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
    +.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
[reply]
[d/l]
[select]
      I have actually recommended that we make a nice perltidy config and apply it to all files when they are checked into CVS. The problem here is that there is now a disconnect between what you just wrote yesterday and what you are editing today. I think coding standards are important in the context of a development team because people tend to get more done when they don't have to spend extra time deciphering yet another individual coding style. For example, we've got numerous styles running rampant: 
      if($this) {
    do_that(); # Pretend this is indented with a tab
}

if ( $this ) {
    do_that(); # another tab
}

if($this)
{
do_that();
}

if($this)
{
    do_that();
}

if($this)
    {
    do_that();
    }

if($this)
    {
        do_that();
    }

      [download]
      And that's only the if statements! And some people use 4 spaces and some use 2. Of course, they become harder to read with more complex statements: 
      if($this)
    {
    do_that();
    eval {
        do_something();
    };

    if($something_else)
        {
        here_we_go();
        }
    }

      [download]
[reply]
[d/l]
[select]

        The problem here is that there is now a disconnect between what you just wrote yesterday and what you are editing today

        Personally I wouldn't care! If the formatting is there so that everyone understands the code more easily, then fine! I should understand my code also. If not, I programmed something so obfuscated, I should rethink it ;-) and that's a positive side effect of the tidy process, don't you agree?

        I'd still (even if I get downvoted more) prefer my own "style" over any company dictated one because I don't want to focus un bureaucraccy ;-) (I'm exaggerating). Let the perltidy do it's work and I will be happy.

        s$$([},&%#}/&/]+}%&{})*;#$&&s&&$^X.($'^"%]=\&(|?*{%
        +.+=%;.#_}\&"^"-+%*).}%:##%}={~=~:.")&e&&s""`$''`"e
[reply]
[d/l]
[select]
        Howdy!

        That's a risky suggestion. Far safer is to insist the people run that standard perltidy pass, and then make sure their code still passes its tests.

        It is possible that perltidy could break code when it reformats it, so ensuring that it still passes all its tests (or at least all the tests it passed before) is important, and having it happen automagically on check-in runs the risk of overlooking that effect while it is easy to undo.

        yours,
        Michael
[reply]

Back to Seekers of Perl Wisdom