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]

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

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

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?

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 ...