What if you unsuccessfully flock() a file... then you open the file for writing, even though the file has not really been locked... expect trouble if you ignore this tip.

Are you serious? No, you can't be. You cannot even do what you describe. You can only flock filehandles - and you only get a filehandle after opening a file. You don't first flock, then open. No, you first open, then flock.

There is absolutely no reason or excuse for using goto().

Really? You'll find people like Donald Knuth and Dennis Ritchie disagreeing with you. While goto ought to be used with caution, there's no reason to flat out forbid it. Not to mention that there's no alternative for goto &sub in Perl - unless you code similar functionality using XS.

I can't imagine a sub named without a verb.

Is new a verb? What about commonly used functions from CGI, like param, header or keywords?

my() is much better (than local)

But my isn't a drop-in replacement for local. Certain things that you can localize, you can't my.

For CGI scripts that need to handle data, CGI.pm is a must, if only for reading CGI parameters. Don't do it by hand. The first time I needed to read in data, I processed STDIN and $ENV{'QUERY_STRING'}... horrible! Avoid it like the plague!

Hmmm, for programs that only need reading in CGI parameters, I think CGI.pm is overkill, don't you? It's a dinosaur (with a bad name), and not exactly a good example of modular code writing. As for processing STDIN and $ENV {QUERY_STRING}, what do you think CGI.pm does? Get the parameters out of thin air?

Yep, I agree completely. I can't really argue why, besides the fact that readability and maintainability are increased. I've just always used uppercase file handles.

I, on the other hand, have hardly used filehandles for the last years (except for the default ones provided by Perl). We have been able to use references to filehandles for filehandle operations ever since 5.000, and since 5.6, open will autovivify one if given an undefined value as first argument.

/me shudders at the thought of a script that uses $a, $b, $c, $d type variables.

Ah, so you prefer:

   for (my $array_index_counter = 0;
           $array_index_counter < @array_of_some_sorts;
           $array_index_counter ++) { ... }
[download]

The Pascal and Java way. I rather keep the tradition of Fortran, Algol and C, and use $i. It's ok for variables of a limited scope to have short names.

Whether as POD or comments, as long as there is at least something to explain what a subroutine does.

Keep your comments brief and short. If most of your subroutines need a lot of comments, it's a sign something is wrong. A good name goes a long way in describing what a subroutine does. And so do named parameters. POD and comments aren't interchangeable. The main purpose of POD is to generate manual pages - it will describe the interface. Comments describe the internals.

if you use 3 lines 10 times in a script... that should most definitely become a subroutine.

 
    open my $fh => $file or die "Whatever: $!";
    flock $fh => LOCK_SH or die "Whatever: $!";
    local $_;
    while (<$fh>) {
        ....;     
    }
    close $fh or die "Whatever: $!";
[download]

That's five, often repeated, lines. You want to factor that out to a subroutine? How often do you think that happens in practise? What about a DBI prepare/execute/fetch combo wrapped in an eval? That's more than three lines as well. Factor it out?

Abigail