Michael Ludwig wrote:
André Warnier schrieb am 25.04.2010 um 12:44:56 (+0200):
...
no warnings 'uninitialized';
is very dubious.
I used to think so, too, but I've recently changed my mind.
...
Michael, I have no doubt that your intrinsic perl knowledge surpasses
mine, but I disagree, not with the details of what you mention, but on
the general spirit and in the context. And I find your quoting of the
common::sense module a bit biased, again not in the details but in the
spirit in which you seem to "recommend" it, again in this context. I
like the module, but in the sense that it seems indeed a useful shortcut
for a number of *explicit* assertions which *some* perl coders use.
Which is what its description honestly says :
"This module implements some sane defaults for Perl programs, as defined
by two typical (or not so typical - use your common sense) specimens of
Perl coders. In fact, after working out details on which warnings and
strict modes to enable and make fatal, we found that we (and our code
written so far, and others) fully agree on every option, even though we
never used warnings before, so it seems this module indeed reflects a
"common" sense among some long-time Perl coders."
However, many years of designing and programming stable and reliable
applications in perl have taught me to prefer explicit code,
understandable and maintainable also by other people; this as compared
for example to relying on assumptions about the compiler's defaults.
And for this OP, who on the face of it is not a perl guru, all the more so.
In my view, code such as
$article_file = $q->param("articlefilename");
(and then proceeding to use $article_file without further ado)
in a web application, is ok if you know exactly what you are doing, and
if you know somehow that the client cannot "not send" this parameter in
the request, and that it cannot send it empty, and that even if it does,
it does not matter all that much anyway; and that the person who
is going to re-read your code in 6 months knows as much about perl's
internals as you do.
$article_file = $q->param("articlefilename") || '';
does not add much technically, since as you rightly mention perl already
does that, in a way (although not at the same time or place). But it
makes *explicit* what you are doing, which makes the difference to
someone maybe not as fluent in perl and who has
to look at that code in a year's time.
In a real web application with which people interact through a browser
and a html form, I would have made it even much more defensive and
explicit, like :
$article_file = $q->param("articlefilename");
unless ((defined($article_file) && ($article_file ne '')) {
return an error of type "essential info not submitted"
}
unless ($article_file is-what-we-expect) {
return an error of type "invalid value submitted"
}
because in this case, that filename seems to be the real essential
element of the application, so I would not want an empty or undefined
value to even create a doubt as to where it comes from or what happens
with it. And I know that this is not elegant code; but it is code that
will survive another version of perl, another version of
Apache::Request, and another version of the programmer maintaining it.
I will qualify all the above by adding that this regards application
code, written and/or read and/or modified by programmers whose skills vary.
It is on the other hand perfectly ok in my view for a perl guru to write
perl modules using whatever clever techniques and idioms suit him, as
long as the module does what it claims to do. And as long as
(preferably) any section of such code comes with ample internal
documentation explaining what it does and what it relies on.
