SPUG: Debugging methodology (was: How to deal with same name
packages?)
Pommert, Daniel
Daniel.Pommert at verizonwireless.com
Tue Jan 29 12:07:55 CST 2002
This all depends what you are used to. If you programmed a lot in C, you
will be less comfortable with non-C syntax. If you programmed a lot in ksh
before Perl became popular, then the "expr && action" syntax is obvious and
natural. Michael's "non-standard indenting" reads well on a printed page
and is very close to what is found in 2nd Camel, pp 104,5. It is also
idiomatically common (in certain circles).
A bigger question here is: How big is your script or routine and how many
other people will be maintaining it? How long will its life be? I have
been quite free wheeling with vector code, closures, morphing objects and
Schwartz transforms when I knew that I would be the primary one maintaining
the code (and I took the time to comment my code clearly). In shops where I
knew my term was short lived and I saw that my coworkers tended to be not
very advanced in Perl, I tended to tone things down a bit. (Although, I
really I really had a hard time weaning myself from those nested map lines!)
IMHO, TMTOWTDI and you need to look at the culture around you.
-- Daniel Pommert
Verizon Wireless
425-603-8612
-----Original Message-----
From: Richard Anderson [mailto:richard at richard-anderson.org]
Sent: Tuesday, January 29, 2002 9:21 AM
To: spug-list at pm.org
Subject: Re: SPUG: Debugging methodology (was: How to deal with same
name packages?)
I still agree with Tim. Michael's example was a straw man. A fair
comparison would be:
return 1 if $n == 1;
return 0 if $n < 1;
versus
if ($n == 1) { return 1; }
if ($n < 1) ( return 0; }
The shortness of this statement makes the first form more acceptable, but it
still states the action of the statement backwards. The point of the
statement is to make a conditional test and if it succeeds, do something.
So the logical and readable way to right it is the second form. This
becomes even more significant with longer statements.
And I think Michael's use of non-standard indenting:
next if /^\s*$/; # skip blank lines
next if /^\s*#/; # skip shell-style comments
adds nothing to the readability of the code.
Cheers,
Richard
richard at richard-anderson.org
www.richard-anderson.org
----- Original Message -----
From: "Michael R. Wolf" <MichaelRunningWolf at att.net>
To: <spug-list at pm.org>
Sent: Tuesday, January 29, 2002 7:55 AM
Subject: Re: SPUG: Debugging methodology (was: How to deal with same name
packages?)
> Tim Maher <tim at consultix-inc.com> writes:
>
> > On Mon, Jan 28, 2002 at 03:08:23PM -0800, Colin Meyer wrote:
> [...]
> > > Or even:
> > >
> > > print (STDERR "Debug statement"), second_thing if $debug > 1;
> >
> > That's just too kinky. I thought the whole idea of this backwards
> > statement was to make the code *easier* to read, not to make it
> > harder to see how much is being executed conditionally!
>
> Kinky? Maybe. Pushing the edge of my one-line limit?
> Probably.
>
> As with all formatting and logic issues in programming,
> there are competing values toward a balance point.
>
> - Don't waste extra curlies for a single-expression block
> - Hilight control flow
> - Hilight normal execution
> - Hilight normal execution
> - Limit expression modifiers to a single line
>
> For example, I think the inverted control flow works better
> in the first example below. The extra curlies, whitespace,
> and punctuation do not add any readability or flexibility in
> the second one.
>
> use Memoize;
> memoize (fib, fluffy_fib);
>
> sub fib
> {
> $n = shift;
> return 1 if $n == 1;
> return 0 if $n < 1;
> return fib($n -1) + fib($n-2);
> }
>
> sub fluffy_fib
> {
> $n = shift;
> if ($n == 1) {
> return 1;
> }
> if ($n < 1) {
> return 0;
> }
> return fluffy_fib($n -1) + fluffy_fib($n-2);
> }
>
> And here, I like that the control flow is easy to see. I
> over-emphasized it by lining up the "if", and it still fits
> on a line nicely. Even when there is something to do before
> next-ing, like the pragma processing.
>
> sub doit {
> while(<>) {
> next if /^\s*$/; # skip blank lines
> next if /^\s*#/; # skip shell-style comments
> do_pragma($_), next if /^pragma\b/;
> doit_toit($_);
> }
> }
>
> Obviously kinky, perverse.
>
> do {
> many lines of code here
> ..
> ..
> ..
> } if condition
>
>
> So I agree with your sentiment. I choose a different
> balance point for short expressions, especially if they tend
> to draw attention to the important part of the clause.
>
>
> There's a different focus to the following (equivalent)
> statements. I utilize this in my English.
>
> Enjoy, it's Perl!
>
> It's Perl, enjoy!
>
> And in my Perl.
>
> enjoy if $is_perl;
>
> if ($is_perl) {
> enjoy;
> }
>
> And of course, TMTOWTDI
>
> $is_perl && enjoy;
>
> if ($is_perl) { enjoy; }
>
> --
> Michael R. Wolf
> All mammals learn by playing!
> MichaelRunningWolf at att.net
>
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
> Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
> Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
> For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
> Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/
>
>
>
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
POST TO: spug-list at pm.org PROBLEMS: owner-spug-list at pm.org
Subscriptions; Email to majordomo at pm.org: ACTION LIST EMAIL
Replace ACTION by subscribe or unsubscribe, EMAIL by your Email-address
For daily traffic, use spug-list for LIST ; for weekly, spug-list-digest
Seattle Perl Users Group (SPUG) Home Page: http://zipcon.net/spug/
More information about the spug-list
mailing list