What really constitutes good programming practices in Perl? Invariably, when the subject comes up people start by pointing out that your programs should start with something like: 
#!/usr/bin/perl -wT

user strict;

[download]
Unfortunately, everything after that seems to break down to anecdotes (definition by example) and suggestions to comment heavily. For instance, I changed some of my code after seeing someone point out a better way to add elements to an array. 
while (<>) {
    $array[$index++] = $_ if /$searchstring/;
}

[download]
This is better written as: 
while (<>) {
    push (@array, $_) if /$searchstring/;
}

[download]
The reason it's often (like everything, there are exceptions) considered better is because we avoid a needless variable, $index, and it's faster because we're not tracking that what happens to that extra variable. Unfortunately, this one example doesn't improve my overall programming. It just helps in this instance.

Perl's syntax flexibility is a great feature that also causes difficulty here. 

if (/$searchstring/) { &doSomething }

&doSomething if /$searchstring/;

[download]
The above code fragments do the same thing, but you get to place the "important part" of the code first. That's great. What's the "important part"? Well, that depends upon the programmer and how well he/she understands good coding practices.

Other times, people will say (and rightly so) that we should consult CPAN modules for good examples. Unfortunately, entry level programmers are often at a complete loss to gain a knowledge of decent programming practices from these because they are so rigorous, that many cannot follow them (um... like me).

Personally, I'm a decent programmer. When programming in other languages, I have been routinely complimented on how idiot-proof and user-friendly they are. This is due, in part, to my use of Warnier-Orr diagrams to outline my program flow, but this is often problematic with event-driven or object-oriented programming. When it comes to Perl, it is such an incredibly rich language that no matter how much I code, I find better, more efficient, ways to do things. I'm at a loss here.

Can someone offer Perl-specific advice? I think a FAQ of good coding practices would be wonderful. Even if all the advice is "definition by example", at least having it in one place would be wonderful.

Replies are listed 'Best First'.
RE: Good coding practices
by cwest (Friar) on Jun 14, 2000 at 05:28 UTC
[reply]
      Casey,

      I think you answered my question, but I see, in reading my post, that I didn't cover everything I intended in my question.

      For example, neither of those docs really explains to the novice programmer the value of code modularization. I'm not just referring to placing reused code in a library. Even within one script, you'll often see people write a subroutine that is named something like "&get_grades" and when you look at the subroutine, it will have all sorts of functionality not related to getting the scores.

      Let's say the &get_grades subroutine takes two arguments: the student and the class. One thing we might want to do is verify that the person running the script has the right to view those grades. Oftimes, you'll see such validation occur directly in the &get_grades subroutine. It really doesn't belong there as it is not directly related to the function of that subroutine. The authorization should probably take place before the subroutine call, or the &get_grades should call another subroutine like &verify_access_rights. That's second nature to many of us, but may not be immediately obvious to the novice.

      Another issue would be code optimization. For many common functions, there are a lot of things we can do to optimize the code. In my orginal post, I mentioned the difference between 

      $array[$index++] = $_;

      [download]
      and 
      push (@array, $_);

      [download]
      The second version is preferable in terms of optimization. Regexes are another great area where common optimization rules can be grouped and demonstrated. For example, virtually everyone knows that $` is a bad thing. But, how many people really pay attention to /o and /i switches? <CODE> while (<>)
[reply]
[d/l]
[select]
      Oops. Got cut off. :( 

      while (<>) {
    if (/Ovid/io) {
        # insert brilliant code here
    }
}

      [download]
      If we know the pattern will never change, having it compile only once via the /o switch is great if the regex is in a loop. But if the target string is always going to be "Ovid" with an uppercase "O", that /i switch is killing performance (any monks feel free to correct my ad-hoc analysis).

      In retrospect, perhaps coding practices like modularization and optimization should be totally separate issues and not dealt with in one post. Further, I realize that an entire book on these issues can be written (has been written?), so this may be beyond the scope of a simple post here on perlmonks. But these are burning issues for me and perhaps I seek instant gratification|nerdvana :)

      Comments?

[reply]
[d/l]

        A COBOL programmer programs COBOL in every language

        I think one of the rules of Perl programming (and programming in any language) is to use the language specific features. Perl is optimized for array and list operations, and it is always better to use the Perl specific features like push and pop instead of some index twiddling. Of course, this requires knowledge of the builtin functions and operators, and such knowledge only comes with the time.

        Regarding your question about placing the if, I say, that is the responsibility of the programmer. I always place the if according to what the current routine / block is supposed to do. If it is only parameter validation or error checking, the if is postfixed, but if the purpose of the whole subroutine is validation, the if might become a prefix. Some fictional example of my "good" coding style : 

          sub checkLine {
    # returns an (error) string that describes
    # what the line contained.
    # I place the if behind the return because
    # if I look at the code, I have an error message
    # and want to know what caused this message.
    return "! found at start of line." if /^!/;
    return "Line too short" if !/.{5,}/;
    return "";
  };

if {/BEGIN/i) {
  # here I use a prefixed "if", because a longer block follows.
};

        [download]

        From all RE engines I have looked at (the Perl RE engine is not with those ;), they implement character matching by using a lookup table of "matching" characters, so it should not make a speed difference whether you use /i or not. I might be wrong for Perl though ...

[reply]
[d/l]
RE: Good coding practices
by mikfire (Deacon) on Jun 14, 2000 at 19:32 UTC
    I think you are addressing several different issues here, but the main one is how to learn/teach perl idiom. I don't think there is an answer, but I can offer my experiences and maybe some ideas in a larger context.

    In four years of studying French, I was astounded one day when my instructor turned to me and said something along the lines of "You grammer is excellent, but you need to start *speaking* French instead of translating English into French".

    The only way I have found to write Perl is to stop writing C ( or shell, or FORTRAN or whatever ) and start writing Perl. That meant, early on, that my code was written once and then refined several times as I replaced C constructs with Perlisms. After a while ( as it "moved into my muscle memory" as my dance instructors say ), I was able to stop translating and start thinking in Perl.

    This rambling narrative brought to you by
    mikfire

[reply]

Back to Perl Monks Discussion