It's a really good idea to mark variables that belong to a routine;
globals can really make debugging a nightmare!
I ∗loved∗ the example code. I've always wished for an infite loop when
applied to my personal platform :)
I will start to work on a basic (oops, sorry!) platform. Maybe it
will just be a standard template that folks can work from, drawing on
the cut & paste library. It might be best to do cut and paste in this
environment rather than bring in a whole mess of code from an include
or lib that won't get used (?)
Mike
--- In
ComputerVoltageSources@yahoogroups.com, "Grant Richter"
<grichter@...> wrote:
>
> 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
> > > >
> > >
> >
>