The final word on GOTO (Don't I wis

[Kim Letkeman]

In article <14061 at lanl.gov> jlg at lanl.gov (Jim Giles) writes:
>Path: mitel!uunet!cs.utexas.edu!tut.cis.ohio-state.edu!rutgers!cmcl2!lanl!jlg
>From: jlg at lanl.gov (Jim Giles)
>Newsgroups: comp.lang.c
>Date: 2 Oct 89 17:36:57 GMT
>References: <1044 at kim.misemi>
>Organization: Los Alamos National Laboratory
>Lines: 13

>From article <1044 at kim.misemi>, by kim at kim.misemi (Kim Letkeman):
>> True. A big procedure is not necessarily badly structured. But that
>> does not make it easy to read. In fact, a procedure that grows beyond
>> your immediate field of view (24 lines on terminals, more on listings
>> and workstations) is *automatically* harder to read since you have
>> less context within your immediate grasp.

>Splitting some codes into several different routines may also be
>*automatically* harder to read.  There is a difference between
>modularization and fragmentation.  The line between varies according
>to the type of problem and the style of programming used.  I have
>seen thousand line codes which were perfectly coherent.  I have also
>seen 24 line code which should have been modularized.

I think that I made it perfectly clear later on in that article that I
advocate structured coding that follows the rules of functional
cohesion. This precludes the very stupid practice of cutting up
cohesive functions just for the sake of modularization.

I find it hard to believe that you have seen a function that was 1,000
lines long and was still "perfectly coherent" (I assume that you are
using this as a euphomism for readable.) I do believe that you have
seen 24 line functions that could have been modularized.  Lots of
people just write that way.

This thread is getting a bit twisted by those who feel that one
pathological case can prove that gotos are ok or that long procedures
are unavoidable. I'd even start to believe this myself if it weren't
for the fact that most of the cases put forth were refuted by others
with code that appeared to do the job just as well without
unnecessarily breaking the rules of structured coding.


-- 
Kim Letkeman    uunet!mitel!spock!kim