This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.
Path: nntp.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!nwnews.wa.com!news3.nwnexus.com!junior.statsci.com!not-for-mail
From: snow@statsci.com (Greg Snow)
Newsgroups: comp.lang.perl.misc
Subject: Re: good perl coding style
Date: 6 Jun 2000 16:55:58 GMT
Organization: MathSoft, Statsci Division, Seattle, WA
Lines: 112
Message-ID: <8hjaeu$aq2$1@junior.statsci.com>
References: <8hhudb$85k$1@nnrp1.deja.com> <brian-ya02408000R0606000223110001@news.panix.com> <960279422.516.0.nnrp-07.c3ad6973@news.demon.co.uk>
NNTP-Posting-Host: melon.statsci.com
X-Newsposter: trn 4.0-test56 (2 Mar 97)
Xref: nntp.stanford.edu comp.lang.perl.misc:316005
In article <960279422.516.0.nnrp-07.c3ad6973@news.demon.co.uk>,
W Kemp <bill.kemp@wire2.com> wrote:
>I think I read that thread, but an extra question comes to mind.
>A C++ programmer commented that 'perl is all the wrong way round'.
>Meaning he doesn't like this type of syntax:-
>
>"do something" if "test condition"
>
>rather than
>
>if (test condition){
> "do something";
>}
>
>I suppose the second looks more like what a C programmer would expect.
>My question is - where did the first style come from? (is it in other
>languages). does it have any real advantages?
The other language that it comes from is English (Larry tried to make Perl
flow like a natural language).
Any time that you read code (yours or someone elses) there are 2
influences on how it reads, what the designer of the language was thinking
when he/she designed the language and what the programmer was thinking
when he/she wrote the program. The more syntatically strict the language
them more that the first one will dominate. Perl was designed with a lot
more flexibility so that there is more of the second available. I
consider this a good thing because I want to know what the programmer was
thinking, I assume that he/she knows more about the immediate problem than
the language designer.
There are several options for conditionals that will all give the same
result when run, the differences are for human understanding. Consider
the following short program:
#!/usr/local/bin/perl -w
use strict;
open(IN, "/path/to/file.txt") or die("couldn't open it: $!");
my ($c1, $c2, $c3);
while(<IN>){
if( /\S/ ){
$c1++;
}
$c2++ if /\S/;
$c3++ unless /^\s*$/;
}
# now do something with $c1, $c2, and $c3
The first conditional is the or after the open function, this is a Perl
idiom. It could be replaced with:
if( !open(IN, "/path/to/file") ){
die "oooops: $!";
}
but that is much uglier, besides how do you read each of those? in the
original we first read the open statement then see and or and know that
the exception is taken care of. The first couple times through a program
we can completely ignore the right side of that or, it take care of the
special case and we care about the general case for understanding the
first couple of times.
With the if statement we first read the if and are primarily concerned
with a conditional, is this true or false? what do we do if it is true?
When we get to the die we realize that this is just the error checking,
but then need to backtrack in our minds to see the true effect of the open
statement (before we were mostly concerned about it's return value, which
is pretty uninteresting if everything goes according to plan).
So which do you think better conveys the intent of the coder?
Inside the loop we have three conditionals, at the end of the loop $c1,
$c2, and $c3 should all contain the number of non-blank lines in the file
(blank meaning nothing or just white space). But in reading the lines,
each suggests a little bit different emphasis.
For $c1 we have an if(){}, this suggests that the conditional is most
important. We first care if there is a non-whitespace character, if there
is do something about it, in this case increment $c1.
For $c2 and $c3 we first see the increment command, then a conditional on
it, putting the emphasis on the increment. We can read these 2 lines as
plain english:
Increment $c2 if there are any non-whitespace characters on the line.
Increment $c3 unless the line contains only whitespace.
To me, the $c2 line implies that most of the lines will be blank and that
we should only increment in the rare non-whitespace cases. The $c3 line
says that incrementing is the standard thing to do, there are just a few
exceptions where we don't want to.
All three conditionals are legitimate and can be used in different
circumstances. Which is used gives us an idea of what the programmer
considered most important and what they expected the data to be like.
hope this helps,
--
-------------------------------------------------------------------------------
Gregory L. Snow | Inertia makes the world go round,
(Greg) | Love makes the trip worth taking.
gsnow@splus.mathsoft.com |
Path: nntp.stanford.edu!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!howland.erols.net!newsfeed.mindspring.net.MISMATCH!news.mindspring.net!newsfeed.mindspring.net!firehose.mindspring.com!netcom18.netcom.com!not-for-mail
From: ebohlman@netcom.com (Eric Bohlman)
Newsgroups: comp.lang.perl.misc
Subject: Re: good perl coding style
Date: 6 Jun 2000 19:09:29 GMT
Organization: MindSpring Enterprises
Lines: 15
Message-ID: <8hji99$1q0$1@slb2.atl.mindspring.net>
References: <8hhudb$85k$1@nnrp1.deja.com> <brian-ya02408000R0606000223110001@news.panix.com> <960279422.516.0.nnrp-07.c3ad6973@news.demon.co.uk> <8hjagr$bch$1@brokaw.wa.com>
NNTP-Posting-Host: c7.b7.09.76
X-Newsreader: TIN [UNIX 1.3 950824BETA PL0]
Xref: nntp.stanford.edu comp.lang.perl.misc:316056
Lauren Smith (lauren_smith13@hotmail.com) wrote:
: I'd answer this question if I could think of any languages where this
: construct was frequently used.
As Greg pointed out, human languages rather than programming languages.
Although Perl has a (not well-deserved) reputation for being unreadable
by humans, Larry actually designed it with natural-language principles in
mind, to give programmers the ability to make their programs more
human-readable. Why? For mostly social, rather than technical,
reasons. The majority of a typical programmer's time is spent doing
maintenance rather than creating new code from scratch, and maintenance
accounts for a majority of the total life-cycle cost of a typical piece
of software. Thus programs *do* get read by humans, and making that
process easier is economically valuable.