SPUG: Debugging methodology (was: How to deal with same name packages?)

Richard Anderson richard at richard-anderson.org
Tue Jan 29 13:33:27 CST 2002


Style considerations based on historical precedent should not take
precedence over considerations based on rationality and readability.  When
people are thinking about conditional actions, they phrase the action as "do
this test, then take the appropriate action".  Code that reflects the actual
sequence of events is easier to read and understand.  The "expr && action"
is not bad, but not as readable and obvious as "if expr then action".  Why
not make it easy for your fellow coders to read your code?

When you are writing documentation, would you write "Next, reset the
registry setting for SysBoot Record to "Secure", close all applications and
reboot your system unless you are running Windows 98, in which case this
will render your system unbootable"?

Cheers,
Richard
richard at richard-anderson.org
www.richard-anderson.org
----- Original Message -----
From: "Pommert, Daniel" <Daniel.Pommert at verizonwireless.com>
To: "'Richard Anderson'" <richard at richard-anderson.org>; <spug-list at pm.org>
Sent: Tuesday, January 29, 2002 10:07 AM
Subject: RE: SPUG: Debugging methodology (was: How to deal with same name
packages?)


> 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/
>
>
>


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
     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