Gavin Laking wrote:
> On Mon, 08 Sep 2003 23:58:16 -0700
> [EMAIL PROTECTED] (R. Joseph Newton) wrote:
>
> > I'm sticking with my guns here. Extended passages of sequential code
> > are the breeding grounds for errors. They become progressively more
> > difficult to debug. As needs change, such code becomes more and more
> > difficult to adapt to those needs. Eventually, such code will end up
> > having to be re-written from the start, because the lack of separation
> > between functional elements will make for unintended side effects of
> > any changes. In short, it becomes garbage.
>
> I happen to agree with this point of view; that if a subroutine or
> function takes up more than a certain amount of space (usually it is
> a 'feeling' that it is inefficient and not a number of lines ;-) ) then
> it is going to have more bugs in it that a shorter piece of code.
Thanks
> I would like to go on record as being a person that is guilty of
> producing inefficient subroutines, or code that is bigger than it needs
> to be- that is part of the learning process;
Totally. Actually, the program I referred to started out as a 70-80 line
flat script, used only for the initial breaking up of a sequential mailbox
into individual message files, and renaming each with the subject line. I
didn't bother about encapsulation at this point because this was an initial
test run--a "proof of concept".
When I was satisfied that the concept worked, and decided to go ahead and
build a more granular system, with multiple indexes, it was clearly time to
restructure and make the code more modular.
I see sequential scripting as just fine for concept tests, for single-use
"get the job done" tasks. For handling complex tasks, well, it just takes
that functional decomposition.
> 3 months from now I
> predict that most of the code I have written will need to be rewritten
> to use new [better] skills and [more efficient] methods I have learned.
> Hopefully, these new skills will extend the reusable parts of my code.
> Feel bad about producing garbage, but accept it happens,
> Don't throw anything away, recycle it!
Some counterpoint from a Guru:
Prototypes are to be used, then thrown away.
-- Bjarne Stroustroup
Creator, C++
programming language
I am not sure that I totally agree with the good doctor, but he makes a very
good point. Hanging on too tightly to the code can keep us frommaking the
basic structural improvements we need to build truly robust applications.
I can think of some examples that cropped up when I was working with VB on
Windows 95.
That OS, while sorta' nice, did have an annoying tenency to crash on an
average of once every day or so. At this time, I was doing some pretty
heavy-duty, and engrossing, projects. Over the time I would be developing a
process, I would often start feeling that certain details I'd written
earlier could be dne better. Since they were working, though, I would
hesitate to go back and redo work already completed.
I would get pretty wrapped up i9n the process, sometimes forgetting to eat
or sleep. I would also often forget to save--for hundreds of lines at a
time. So when Windows would crash, I would find myself with my last 12
hours of of work vanished into the ozone.
Strangel;y enough, I can not think of a single instance in which the crash
left me with regrets in the long term. When the program is toasted anyway,
there is much less to lose by restructuring. As long as it all had to be
writtenover anyway, I could go ahead and make those little changes that I
had been hankering for.
Because I had already developed a working prototype for the process, the
rewrite would usuqally take about a quarter of the time that the original
composition had, and with more solid code as a result.
Joseph
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
