do...until wisdom found...

Dennis Baker drbaker at softhome.net
Tue Apr 17 18:28:58 EDT 2001


On Tue, 17 Apr 2001 13:01:05 -0700 Bob Cannard <bob_cannard at mentor.com> wrote:

) 
) 
) Dennis Baker wrote:
) > 
) > On Tue, 17 Apr 2001 09:28:15 -0700 Bob Cannard <bob_cannard at mentor.com> wrote:
) > 
) > ) Has no one else found that the majority of while-type
) > ) loops actually need some code before the test and some
) > ) after? Doubly so in Python where it seems impossible
) > ) to embed a local side effect in the while condition.
) > ) As a result, most non-for loops degenerate into
) > )
) > )         while 1:
) > )             set up for this cycle
) > )             if c: break
) > )             whatever needs to be done
) > 
) > That's a product of poor design.  I consider it a failure to resort to this sort
) > of construct. The only time I resort to it is with Error trapping code where
) > you are forced to do something drastic. For the purpose of debugging code
) > readability and reliability you are always better off doing things the "Right"
) > way.
) 
) I was waiting someone to say that.
) 
) No, Dennis, it's not a product of poor design. It's a product of
) examining many problems with clear eyes, without the distorting
) lens of a widely-accepted but insufficiently questioned dogma.

This is my punishment for using absolute terms and an insulting tone in a public
forum.  Lucky I didn't get royally flaimed.  Let me rephrase and retreat a bit.
I avoid using the "while true" construct unless there is no other practical way to
get the job done.  In my experience jumping out of the middle of a code block is
a poor tactic which leads to hard to track down errors and bugs. I rewrote your
bit of code in another thread like this:

  set up for initial cycle
  while !c:
     whatever needs to be done
     set up for next cycle

You would probably class this as duplication of code.  Personally I've found that 
I don't do the same things when initializing a loop and subsequent iterations 
through the loop.  Consider the very simple form: x=x+1 breaks if x isn't 
initialized (I suppose this is poor example, the for loop would be probably
be more suitable in this case).  

Yes, there are many cases where you can justify poor programming technique
some way or another and in any specific case you MIGHT be right.  However you
said "As a result, MOST non-for loops degenerate into..." which infers that
this is a general case.  

-- Dennis

) 
) There are always ways that the general loop can be transformed
) into a while loop. Every single one of them involves additional
) complexity: code duplication, the addition of flag variables, a
) break statement, or the construction of an iterator. The break
) statement and the iterator are the only transforms that do not
) divorce the structure of the source code from the structure of
) the problem.
) 
) The iterator is IMO the most satisfactory of these, but I also
) need to get my job done and my software to meet its performance
) requirements; together they do not allow the luxury of using
) an iterator every time. I don't like using break statements, but
) I dislike them less than the alternatives: code duplication (a
) bug waiting to happen) or flag variables (spaghetti data, the
) structured programming zealot's solution to spaghetti code). And
) the break statements would not be necessary at all if the general
) loop - which is (unknown to many) supported directly and
) successfully by many languages, including the Bourne shell and
) its descendants such as bash and ksh - was carefully considered
) instead of being dismissed out of hand as not canon.
) 
) To say that the "while" loop is the "right" way is to simply
) accept the dogma. The while loop should be a tool, not a
) religion, and like all tools it is not suited to all situations.
) Practical experience - over and over again, through my 25 or so
) years in this business - shows clearly that the it is
) usually ill-matched to the problem; the very existence of
) iterators such as xreadlines is testament to this. Whereas most
) branches of engineering accept the sound principle that form
) follows function, software engineering seems to insist on
) using a form that is clearly ill-suited to the function, and
) instead bludgeons the function until it fits the form. You
) will find yourself hard pressed to convince me that this makes
) a program clearer, more reliable, and easier to debug.
) 
) Cheers,
) 
)        Bob.
) -- 
) http://mail.python.org/mailman/listinfo/python-list
) 




More information about the Python-list mailing list