Absolutely 100% agree. I took two years of structured Basic programming, and everthing
you said is structured basic philosophy. In structured Basic there are only two goto
statement, at the end of mainline code which says GOTO START or some condition is met
which says GOTO END. Excess use of unconditional branching (GOTO) produces
untraceable results (spaghetti code).
Structured Basic mainline code is like this:
FACTORY_JOB:
GOSUB GET_UP
GOSUB WORK_AT_JOB
GOSUB SPEND_EVENING_AT_TAVERN
LET LIVER_CELLS = LIVER_CELLS - 50,000
IF LIVER_CELLS < 0 THEN
GOTO FUNERAL
ENDIF
GOSUB SLEEP
GOTO FACTORY_JOB
FUNERAL:
END
All the primary gosubs call more detailed gosubs (JAGERMEISTER_SHOTS) and so on.
Everybody has had to cheat on this rule when they can't figure out an elegant way to
branch. But avoiding the use of GOTO is a good idea.
Since all Basic variables are global, another tip is to code variable names by subroutine.
First subroutine, all variable names start with A....
Second subroutine, all variable names start with B.....
You get the idea.
--- In
ComputerVoltageSources@yahoogroups.com, "Mike Marsh" <michaelmarsh@...>
wrote:
>
>
> That may be all we can hope for: a cut & paste library of pre-written
> useful stuff with some standards so people don't get too confused.
>
> So, just to start the conversation, I vote to keep the main loop as
> small as possible through the use of subroutines and functions. Don't
> use goto if you can avoid it. I realize the performance issues here,
> but unless it is absolutely clear that the stack overhead is hindering
> an algorithm, I suggest modularity. Both for readability and
> standardization purposes.
>
> I'm ducking now, so fire away...
>
> Mike
>
> --- In ComputerVoltageSources@yahoogroups.com, "djbrow54" <davebr@>
> wrote:
> >
> > Good point. It would be an excellent opportunity to talk about
> > libraries and such. Alas, I had the same experience with include as
> > I did with C. I can't get it to work. I've tried it all sorts of
> > different ways. I've posted help on the forums. I don't know
> > anyone that ever got it to work. As such, all my programs are
> > monoliths. I do have a template that I start with but then when I
> > upgrade code I only sometimes retrofit it back into previous
> > programs.
> >
> > Certainly we should define some fundamental subroutines and variable
> > names. I've put a lot of utility routines in my template. For
> > example, with the display I've written routines for byte to 3
> > character ASCII (e.g. with leading 0's), degrees to 3 character
> > ASCII, byte to SpeakJet, input averaging, etc.
> >
> > If interested, I can generate a list of my 'useful' subroutines.
> >
> > Dave
> >
> > --- In ComputerVoltageSources@yahoogroups.com, "Mike Marsh"
> > <michaelmarsh@> wrote:
> > >
> > > Hi All -
> > >
> > > We have been discussing the hardware architecture to some detail
> > here
> > > (which is good) but what about the a software
> > > architecture/framework/toolkit? A good standard in this area will
> > > facilitate code exchange and get stuff up quickly.
> > >
> > > Mike
> > >
> >
>