Front page | perl.perl5.porters |
Postings from April 2010
In-Reply-To: Message from Jari Aalto <jari.aalto@cante.net>
of "Sat, 03 Apr 2010 02:42:26 +0300."
<87tyrt5sm5.fsf@jondo.cante.net>
Dear Jari,
Believe me, beginners very much want to see parens surrounding function
call arguments. After twenty years of teaching them Perl, I long ago came
to agree with them. It hurts nothing, and helps much. It's terrifically
easier to just put them in than to teach people when it's safe not to.
I've seen too many disasters to counsel anything less than that.
In my own code, about the only functions that don't always get parens are
those I'm calling with a (possible) dative argument, because I don't like
to see the invocant abutting the first argument without a comma separating
the two of them all nestled there inside those parens; it's too creepy.
This exclusion also covers those that more routinely take code blocks in
the dative position, like map(), grep(), and sort(). So yes, I do write
time() and localtime(). It's a good idea. Trust me.
As for && and ||, just who do you think think it is out there who's using
Perl for programming? It's not valid to pull random passersby off the
street and test your taxi-driver's or your barkeep's understanding of
computer code. That's ridiculous! You can't expect someone to be able to
read a language they don't know how to read: that's worse than ridiculous.
There aren't very many people programming in Perl who haven't ever seen
shell or awk or C or C# or C++ or Java or Javascript or Ruby or Haskell
or any of a zillion other related languages that all use && and || as
boolean operators. Punctuation, yes including && and ||, makes it easier
to see the structure whereas and and or or any other word that looks like
an identifier but confers structure does nothing but confuse it.
Perhaps I have a special kind of brain damage from having cranked out
100,000 lines of C code before I left university, and this prejudices
my brain into reading structure easily in code that looks more like C
than it does porridge. If so, then so be it; I'm hardly alone.
Also, I see you keep using single quotes for strings that don't need them.
Why? Those aren't really a generic string, you know. They loudly scream
"DO NOT INTERPOLATE ANYTHING HERE!!!", so I always scrutinize them extra
hard to try to figure out what it is that you're trying to suppress. Plus
I hate having to deal with backslash escapes that aren't. Perl strings
normally interpolate, and it takes something special to suppress that:
$string = $normal ; # interpolate values normally
$string = "$normal" ; # interpolate values normally
$string = `$normal` ; # interpolate values normally
$string = '$abnormal' ; # DON'T INTERPOLATE VALUES!!!
$string = \$abnormal ; # DON'T INTERPOLATE VALUES!!!
$string = "\$abnormal" ; # DON'T INTERPOLATE VALUES!!!
$match = /normal/ ; # interpolate values normally
$match = m(normal) ; # interpolate values normally
$match = m'abnormal' ; # DON'T INTERPOLATE VALUES!!!
func($x); # interpolate values normally
func("$x"); # interpolate values normally
func(`$x`); # interpolate values normally
func(\$x); # DON'T INTERPOLATE VALUES!!!
func('$x'); # DON'T INTERPOLATE VALUES!!!
func(qx'$x'); # DON'T INTERPOLATE VALUES!!!
<<TOKEN # interpolate values normally
<<"TOKEN" # interpolate values normally
<<`TOKEN` # interpolate values normally
<<\TOKEN # DON'T INTERPOLATE VALUES!!!
<<'TOKEN' # DON'T INTERPOLATE VALUES!!!
Besides being the more normal kind of quote for the more normal kind of
string operation, double quotes are also much easier to read than are
single quotes, because they're bigger and easier to see and can't be
confused with backquotes in a font-dependent manner.
I realize that not everybody shares viewpoints on all these things. That's
perfectly fine. I also realize that plenty of people do share these views,
and that deserves to be recognized not extinguished.
What I don't want to see is for the morality mavens of political
correctness to mindlessly extirpate from the standard documentation all
of these perfectly reasonable constructs that are in widespread use in
our community. Perl doesn't need code police with exclusionist agendas.
It's never had them and never should, and the standard documentation
should reflect that position.
Gosh, that sounds harsh! I don't want to scare you away. I know you're
trying to help. It really is appreciated. I just don't like being told
there's something wrong with my programming, particularly when there isn't.
I've been doing this for a long time, and what's not broken needn't get
"fixed"; that's something they do to turn stallions into geldings. Ouch!
--tom
--
Almost nothing in Perl serves a single purpose.
--Larry Wall in <199712040054.QAA13811@wall.org>
Thread Previous
|
Thread Next