Front page | perl.perl5.porters |
Postings from April 2010
On Sat, Apr 3, 2010 at 22:38, Tom Christiansen <tchrist@perl.com> wrote:
> Yes, it's somewhat clearer to write:
>
> for my $tick (reverse 1 .. 10) { ... }
>
> for our $Arg (@ARGV) { ... }
>
> And I do admittedly do this in my own code, except perhaps for implicit $_.
>
> However, I truly do not believe cluttering every example with a declaration
> for each variable used makes it clearer or better. An example that
> demonstrates, say, the abs($x) function, should be able to be written
>
> $x >= 0 ? $x : -$x
>
> without any needlessly distracting declarations.
>
> Eh?
>
> ########################
>
> Similarly,
>
> dbmopen(%HIST,'/usr/lib/news/history',0666);
> while (($key,$val) = each %HIST) {
> print $key, ' = ', unpack('L',$val), "\n";
> }
> dbmclose(%HIST);
>
> is not improved by being written
>
> dbmopen(my %HIST,'/usr/lib/news/history',0666);
> while (my($key,$val) = each %HIST) {
> print $key, ' = ', unpack('L',$val), "\n";
> }
> dbmclose(%HIST);
> [ *snip* ]
I agree that there's certainly a balance to be struck here. It's
appropriate that documentation contain both complete programs and
snippets. Good points have been made on both sides of this discussion.
However, today most Perl programs are written under `use strict' and
most people who read reference documentation are doing so because
they're trying to get from A to B with their program. Now when they
copy/paste a lot of our examples into their programs they get this (to
use the example above):
Global symbol "%HIST" requires explicit package name at /tmp/fail.pl line 3.
Global symbol "$key" requires explicit package name at /tmp/fail.pl line 4.
Global symbol "$val" requires explicit package name at /tmp/fail.pl line 4.
Global symbol "%HIST" requires explicit package name at /tmp/fail.pl line 4.
Global symbol "$key" requires explicit package name at /tmp/fail.pl line 5.
Global symbol "$val" requires explicit package name at /tmp/fail.pl line 5.
Global symbol "%HIST" requires explicit package name at /tmp/fail.pl line 7.
Execution of /tmp/fail.pl aborted due to compilation errors.
Except in very odd cases you want to declare all your variables with
my or our in Perl. Switching between both styles makes the programs
harder to copy/paste and increases the cognitive load for readers
unfamiliar with Perl.
Similarly regarding || v.s. "or" you should expect newbies to do silly
things like improve the style of their program by removing parens.
Thus you should give them "or" because it's the least likely to break
in that case:
open(my $fh, "<", $file) or die "Oh nohes"; # OK
open my $fh, "<", $file or die "Oh nohes"; # Removed parens: OK
open(my $fh, "<", $file) || die "Oh nohes"; # OK
open my $fh, "<", $file || die "Oh nohes"; # Removed parens: FAIL
Actually these days we should just avoid the whole issue and recommend this:
use autodie;
open my $fh, "<", $file;
Thread Previous
|
Thread Next