On Tue, 7 Jan 2003 20:39:29 -0800
Jeremy Zawodny <[EMAIL PROTECTED]> wrote:
> On Tue, Jan 07, 2003 at 07:46:33PM -0600, G. Wade Johnson wrote:
>
> > But it occurs to me that a large portion of what you need to write
> > good Perl is a firm understanding of Perl's idioms.
>
> Really?
>
> Can you elaborate on that? It sounds like you're just saying that
> "good perl looks like ..." but I suspect there's more to it than that.
Sure, I'll try.
Unlike some languages, Perl has several ways to solve almost any
problem. So how do you choose which solution to use? If there was
one best way to, for instance, write conditional statement or a
loop, Perl would only have one way to do these things.
We choose which of Perl's features to use based on the "extra"
information that that particular idiom provides. The "extra"
information is what makes our intent plainer to the next programmer.
For example,
# Example1
if(0 == $success)
{
do_something():
}
# Example 2
unless($error)
{
do_something();
}
# Example 3
do_something() unless $error;
All of the above examples (and others) do the same thing. But each
implies something different to the human that reads it.
In Example 1, the important fact appears to be whether or not $error
is zero. If it is zero, we need to "do something".
In Example 2, the important fact is that $error is not true. If it
is false, we need to "do something".
In Example 3, the important fact is that we want to "do something".
But we only want to do it, if $error is false.
All of these pieces of code will do basically the same thing. Only
the last emphasizes "doing something" over the error test.
This was just a simple conditional, some other Perl idioms carry
even more meaning for the next programmer.
Later,
G. Wade
--
It's easier to port a shell than a shell script. -- Larry Wall
