Dave Golden wrote:
> Jan Dubois wrote:
> > So any feedback on the style /content would be welcome.
> I really liked that you discussed good style and some defensive
> coding, even though that wasn't required by the competition.
> "open or die" -- I personally think it's good style to die with at
> least "$!" so there's some feedback as to what happened.
It strikes me that commentary at this level should be of two types --
interesting or unusual algorithms or data structures for solving the
problem, and stylistic recommendations.
For the latter, I've been plowing through Conway's book,
_Perl_Best_Practices_. It seems to me you can't talk about style without
at least a nod to it.
For example, on error checking IO, Conway's dicta is "Never open, close, or
print to a file without checking the outcome." And he offers
open my $out, '>', $out_file or croak "Couldn't open '$out_file':
$OS_ERROR";
($OS_ERROR you may be asking yourself? Conway is a big fan of 'use
English' instead of potentially obscure mnemonics. Sadly, since I've used
$! when what I really meant was $dbh->errstr(), he is probably right.) He
also points out that there is a perhaps better way "Make failed builtins
throw exceptions too" with the use of 'use Fatal'. This is pretty cool.
Now
#!perl -w
use strict;
use Fatal qw(open);
open my $fh, '<', 'foo.bar';
print "Hi, Mom!\n";
when executed, yields
C:\Documents and Settings\Administrator\My Documents\random perl>test.pl
Can't open(GLOB(0x226268), <, foo.bar): No such file or directory at (eval
1) line 3
main::__ANON__('GLOB(0x226268)', '<', 'foo.bar') called at
C:\Documentsand Settings\Administrator\My Documents\random perl\test.pl
line 5
Very, very smart. Add something like 'use Fatal qw( open close );' into
your boilerplate (I can't bring myself to trap every bloody print statement
like Conway suggests) seems like a pretty sound idea.
Or, in terms of Dubois' style,
chomp(my $number = <>);
This looks ugly to my eye. His point was "don't do $number = chomp(<>)"
pointing out that some people are confused about what chomp returns. But
why not
my $number = <>;
chomp($number);
Its more clear, I think, and allows for slightly cleaner debugging if
needed. But that is pretty small potatoes compared with the key logic of
his approach
eval "tr/$letters\L$letters\E/$digits$digits/";
He correctly points out that tr doesn't support interpolation at run time,
so we have to put this inside an eval... but isn't the correct conclusion
is that this is probably too complicated for what is essentially a really
easy task? Or the very clever approach of building a custom regex via join
q{}, map { "[$num2chars[$_]]" } split //, <STDIN>, 7; -- okay, but again, I
think I'd argue that clever is probably bad. Conway has a dicta for that,
too: "Don't be clever." His observation is that while Perl provides
endless opportunities for cleverness, its the natural enemy of maintainable
code.
I think my approach would have been to set up a hash table mapping chars to
digits, then do what David did with his regex via hash lookups.
But then, perhaps I'm being silly. This is only a game. But I do want to
give a big thumbs up to Conway's book.
--woody
--
Let me assure you that to us here at First National, you're not just a
number. Youre two numbers, a dash, three more numbers, another dash and
another number. -- James Estes_______________________________________________
Perl-Win32-Users mailing list
Perl-Win32-Users@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
