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.
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4