Re: Software landmines (loops)

[mfinney@lynchburg.net]

In <6simjo$jnh$1@hirame.wwa.com>, "Robert Martin" <rmartin@oma.com> writes:

>mfinney@lynchburg.net wrote in message ...

>>And, as far as maintainability is concerned, I strictly use tree-structured
>>programming and have *never* found it to be a maintenance problem.
>>Sure, sometimes code transformations are required during maintenance,
>>but they are sometimes required during coding.  So what?  There is no
>>way to write code that never requires code transformations during
>>maintenance, and trying to do so just makes the code harder to
>>understand and ultimately increases maintenance cost.  Far better is
>>to endevour to reach 0 bugs so that maintenance is never required.
>>Not easy, perhaps, but it is getting closer and closer every day.  I
>>personally am running somewhere around 0.0001 and 0.0002 errors
>>per line of code --  prior to quality assurance getting the code.

>Reaching zero bugs may not have that big an impact on maintenance, since
>much of maintenance has to do with changes to the requirements.

Reaching zero bugs means that changes are made by development
rather than maintenance.  That distinction is, of course, a matter of
definition.  It also depends on the ratio between code correction and
requirement changes.

>In any case, I note that in this thread nearly every article that advocates
>multiple exits evokes either readability, complexity, or naturalness as the
>justification.  I contend that these are highly subjective things, that are
>not shared by all programmers alike.

Certainly true.  But there does tend to be a rough consensus.  Discussions
like this tend to refine that consensus.

>I also contend that
>these issues are somewhat emotional, as evidenced by the terms such as
>"twist", "warp", "bend", "religious argument", etc. that have also been used
>in this thread.

Quite true, although for the record I must say that I used the term "twist"
as a synonym for "roll" or "rotate" and in an emotionally negative manner.
The terms "warp" and "bend" were used to indicate the emotional "feel"
of forcing code into a perceived unnatural state.

>So, it seems what we have here is "gut feelings" warring against empirical
>data.

I would not agree with that.  First, the "benefits" of structured programming
have not been shown that clearly, and second, there is evidence on the
other side as well.  And, generally what was measured in most studies that
I have seen is the difference between structured programmend and completely
unstructured programming.  Not the difference between structured programming
and tree-structured programming which is the point of this argument.  The only
study quoted so far, favors the middle exit which is actually irrelevant to the
difference between structured programming and tree-structured programming.

>In the end, the decision to use a structured style is a tradeoff.  There are
>benefits, and there are costs.  And there are certainly situations in which
>the costs outweight the benefits (e.g. quick an dirty programs that have
>short lifetimes and require little maintenance during their life).  It is
>also true, however, that for a very large set of circumstances, the benefits
>outweigh the costs.

First, I don't know about you, but I don't write "quick and dirty" programs.
I write all programs in the same manner, regardless of their audience or
intended lifespan -- those targets change far too frequently.

Secondly, the benefits of structured programming over tree-structured
programming have *not* been demostrated, so far as I know.


Michael Lee Finney