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 ++) { ... }
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: $!";
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