ComputerVoltageSources

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
> > > >
> > >
> >
>