On Fri, 23 Jul 1999, Rob Cozens wrote:
> >It's harder to develop this
> >way because the important routines end up getting scattered over
> >several handlers, but is the only way to go, especially for
> >time-critical applications like games.
>
> I had come to assume this is what you referred to as "spaghetti code",
> Scott, and I have even gone so far as to wonder what the better way was.
Not exactly.
> What is spaghetti code and how should one avoid it?
The way I use it, "spaghetti code" is just *unnecessarily*
complicated. It's not as common today as it was in the days of BASIC
and Fortran where a significant fraction of flow control was handled
with GOTO and unnamed (and usually undocumented) GOSUB routines.
These things make the code extremely difficult to understand and
modify without breaking something.
Granted, doing fully event driven design is more complicated than
putting everything in-line and using "wait", but it's *necessary* to
provide good response and efficient CPU utilization. And even this is
nowhere near as complicated as dealing with other alternatives like
multithreading or most other callback-oriented architectures (e.g.,
MacOS asynchronous callbacks, which are a real nightmare because you
can't do anything that requires allocating or freeing memory in them).
Regards,
Scott
> Rob Cozens, CCW
> http://www.serendipitysoftware.com/who.html
>
> "And I, which was two fooles, do so grow three;
> Who are a little wise, the best fooles bee."
>
> from "The Triple Foole" by John Donne (1572-1631)
>
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
