in reply to RE: Good coding practices
in thread Good coding practices

Oops. Got cut off. :(

while (<>) { if (/Ovid/io) { # insert brilliant code here } }
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?

Replies are listed 'Best First'.
Good coding practices / Case Insensitive RE matching
by Corion (Patriarch) on Jun 14, 2000 at 13:56 UTC

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

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