Re: Perl best practices (was: question ... Split operator in Perl)
I highly recommend Damian Conway's book of same title, Perl Best Practices, which recommends a much tamer, consistent readable style within a workgroup than he uses in his own code (depending on context) -- he suggests one style but encourages each group to decide for themselves and take his list of 255 practices as a template for their own local standard. http://www.oreilly.com/catalog/perlbp/ -- Bill [EMAIL PROTECTED] [EMAIL PROTECTED] ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
Bill Ricker writes: I highly recommend Damian Conway's book of same title, Perl Best Practices, which recommends a much tamer, consistent readable style within a workgroup than he uses in his own code (depending on context) -- he suggests one style but encourages each group to decide for themselves and take his list of 255 practices as a template for their own local standard. I will second this. Great book by a great author. Regards, --kevin -- GnuPG ID: B280F24E Error messages alumni.unh.edu!kdc strewn across my terminal. A vein starts to throb. -- Coy.pm ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
On 9/13/07, John Abreau [EMAIL PROTECTED] wrote: s/^[\x20\t]*//; # trim leading space s/[\x20\t]*$//; # trim trailing space Any particular reason to use [\x20\t] instead of \s ? \s would also eat newlines and similar. At a minimum, it would have to explicitly print with \n and use the -n switch instead of the -p switch. Which would be fine. But if the file contains non-native line endings, it can result in those getting mangled, or so I've found. I've got a lot of such files hanging around on my system. Just eating space and tab worked better for me. OTOH, \s should eat other kinds of in-line whitespace that might be encountered, including anything Unicode dishes up. So that might be better for some situations. YMMV. Or, since this is Perl we're talking about: TIMTOWTDI. ;-) -- Ben ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Perl best practices (was: question ... Split operator in Perl)
On 9/12/07, Paul Lussier [EMAIL PROTECTED] wrote:
You don't need to put parenthesis around arguments to split, and you
don't need to explicitly specify the default pattern match target
($_).
Unfortunately, you both don't *need* to and *can* do anything in
perl. Often at the same time! This is what leads to very difficult
to read, and more difficult to maintain perl code.
Well, this is something of a religious issue. :) But here's my opinion:
Personally, in the proper context, I find this:
@foo = split m{blah};
to be easier to read and comprehend at a glance than this:
@foo = split (m{blah}, $_);
The proper context being a loop or other pattern where I'm running
a series of operations on a series of inputs (i.e., lines). In those
contexts, where the whole point is to perform a series of operations
on each input, assembly-line fashion, using the the implicit argument
lets me focus on what the code is actually *doing*. Explicitly
specifying $_ over and over again just clutters up the code with
pointless syntax. It's one more thing my brain has to recognize and
process.
I don't arbitrarily assign to $_ and use it at random, the way some
people do. And I do make use of parenthesis, braces, and such, even
when they are not needed, when I find it makes the code clearer. But
I also leave them out when I find it makes the code clearer.
For a slightly less contrived example, take a script which trims
leading and trailing whitespace from each line in an input file. I
already have one implementation, and I just wrote up another one.
Here's one of the possible implementations:
#!/usr/bin/perl
$filename = $ARGV[0];
if ($filename eq ) {
open(INPUTFILE, STDIN);
}
else {
open(INPUTFILE, $filename) or die(could not open input file!);
}
while(not(eof(INPUTFILE))) {
$line = INPUTFILE;
$line =~ s/^[\x20\t]*//; # trim leading space
$line =~ s/[\x20\t]*$//; # trim trailing space
print($line);
}
And here is another possibility:
#!/usr/bin/perl -p
s/^[\x20\t]*//; # trim leading space
s/[\x20\t]*$//; # trim trailing space
Assuming the reader is familiar with the language, which do you
think will be easier/quicker to comprehend?
It may be true that someone who *isn't* familiar with Perl would
find it easier to puzzle out the meaning of the longer version. But I
don't find that a particularly compelling argument. I write Perl
programs with the assumption that the reader understands Perl, the
same way I am assuming readers of this message understand English. :)
This may mean Perl, as practiced, is harder to learn than a language
which is more rigid and always verbose. Many say similar things about
Unix. Or Emacs. :-) I'm don't argue that one approach is right and
the other wrong, but I do think that both approaches have their
merits.
YMMV.
-- Ben
___
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
Re: Perl best practices (was: question ... Split operator in Perl)
On Wed, September 12, 2007 9:37 pm, Ben Scott said: s/^[\x20\t]*//; # trim leading space s/[\x20\t]*$//; # trim trailing space Any particular reason to use [\x20\t] instead of \s ? -- John Abreau / Executive Director, Boston Linux Unix IM: [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Email [EMAIL PROTECTED] / WWW http://www.abreau.net / PGP-Key-ID 0xD5C7B5D9 PGP-Key-Fingerprint 72 FB 39 4F 3C 3B D6 5B E0 C8 5A 6E F1 2C BE 99 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
