Loadstar 215/215.d81/t.basics

Text File | 2022-08-26 | 9KB | 358 lines

u
    B E G I N N I N G   B A S I C

       "The Top-Down Approach"

         by Jeffrey L. Jones

    You're about to start on an
application program.  It's a phone
list manager.  You type in the first
line:

10 poke53280,0:poke53281,0:print[CLR]


    Okay, you know what color the
border and background are going to be
but what about the program itself? How
will you create a usable program from
what is essentially a thought? What
I'm about to say might go against some
people's natural urges but the
"top-down" approach is usually the
best (as well as fastest) way to to
create programs.

    Top-down means basically creating
the interface (menus) first, then
creating the guts of the program. You
print the menu on the screen, even
have a working highlight bar. If an
item on the menu should have a
sub-menu, get that working, too. So
essentially you start off with a
program that looks finished, shows you
most of its functions, but doesn't
work. In my book that's one level
better than starting off with a
program that DOESN'T look finished and
doesn't work to boot. This gives you
an animated outline of the finished
product. With the main menu working,
at least you can visualize how the
program will work and not leave
anything out.

    Imagine building the elevators and
cafeteria before the building. At
least if you wait till the building is
erected and floors assigned, you'll
know how many buttons to fit into the
elevators, and which floors should be
skipped. The old horse before the cart
syndrome is similar to creating a
program before creating its interface
with the user.

    Filling in your hollow program
becomes a relative breeze. All you do
is "fill in" the features, starting
from the top of your menu and working
your way down. Programming this way,
you'll discover that the program
almost writes itself for you.
Additionally your code will
automatically become sectioned and
easily modifiable. You're
sub-routining and even writing
structured code without having to
think about it. You may also find that
in the process of filling in features,
you're creating routines that other
features can use to get their jobs
done.

   -----------------------------
    PITFALLS TO SUBROUTINING
   -----------------------------

    While on the subject of
subroutining, three commonly wasteful
practices used by many programmers
are:

    a. Clearing lines on the screen
    b. Plotting the cursor
    c. Overcoming line link problems

    Probably no one sees as much of
other people's code as we do. The
aforementioned tasks commonly cause
budding programmers to make the
mistake of defining large strings over
and over again, which eventually take
their toll through garbage collection.
Garbage collection causes your
computer to pause while it cleans up
the mess that the programmer has made
of memory. Garbage collection is
almost always the programmer's fault.

    These pitfalls also take their
toll by making programs larger. I'm
not talking a little larger -- I'm
talking about programs that we've
published at 60-blocks that were 110
when we received them.

  To clear a line on the screen,
please DON'T define 40 spaces and
print them. Instead:

  POKE 781,line:SYS 59903

  In assembly language:

  LDX #line
  JSR $E9FF    ;59903

    To clear a range of lines, do it
in a FOR NEXT loop.

    To plot the cursor on a particular
row and column, just do the following
in BASIC:

  POKE214,row:POKE211col:SYS 58732

    That is the most efficient way
for BASIC.  In assembly language the
KERNAL PLOT routine is better
suited:

  LDX #row
  LDY #column
  CLC
  JSR $FFF0

    To TAB backwards:

  POKE 211,column:SYS 58732

    In assembly language:

  LDA #column
  STA 211
  JSR 58732    ;$E56C

    Lastly, line links are a major
cause of bad code. Because lines on
your screen can bcome "linked", you
may have fewer than 25 logical lines
on your screen (as few as 13). Your
screen editor links lines because
when you're typing in programs, one
line may wrap around.  So the
computer has to "link" the two lines
that the code takes up and consider
them one line. This is a neccesary
evil, while you're coding, but it
becomes a hassle when the editor
continues to link lines when it
doesn't have a need to (while your
program is running). In general, any
time you print to the 39th column,
lines are linked. If the line
immediately beneath the line to be
linked is already linked, that
section of the screen is scrolled
down.

    So you know that you want to move
to line 12, but every time you try to
plot the cursor there, it lands on
line 15. The only way to get the
cursor where you want seems to be
physically printing HOME and a series
of CRSR DOWNS. This wasteful tactic
is usually compounded by X number of
CRSR RIGHTS to the desired column
position.

    The logical solution to the line
link problem would be to unlink the
lines. This can be done in a FOR
NEXT loop:

  FORI=217TO242:POKEI,PEEK(I)OR128:
NEXT:RETURN

    In assembly language:

  LDY #24
  LINKS LDA 217,Y
  ORA #128
  STA 217,Y
  DEY
  BPL LINKS
  RTS

    Note that I made both versions
into subroutines since you may need
them many times.

    Main menus are usually the cause
of linked lines. By the time you've
gotten it presented, you've printed
to the 39th column more than a few
times. So right after you finish
your main menu (or any major revision
to the screen) you should clear your
line links by GOSUBing to a subroutine
that does it. Or even better: Don't
print to the 39th column.

    I mention these programming
tactics because they'll make your
programs shorter and more efficient.
Moreover, you'll find that your
programs act as you expect them to.
Bugs are a cinch to fix.  When
anything goes wrong, you know what to
change.

 -----------------------------------
 B A S I C   A N D   T O P - D O W N
 -----------------------------------

    One BASIC command invaluable to
top-down programming is ON
GOTO/GOSUB.

    ON GOTO is a highly under-used
but useful command. It not only
gives you the power to dispatch
control of a program to many lines
with one command, but also offers
extended IF THEN logic if you know
how to use fancy formulae (BASICS
#66).

    When used normally, you shove a
value (n) at ON GOTO and it turns
over program control to the nth
line:

10 GET A$:IF A$<"1" OR A$>"5"THEN 10

20 ON VAL(A$)GOTO 150,160,170,180,190


    On line 20 the program can GOTO
any of 5 lines. Line 10 makes sure
that a value between 1 and 5 is
given.  If the value is 1 then the
program will branch to line 150.  If
the value is 3 the program will
branch to line 170 (or item 3 in the
list).

    If somehow A$ gets to this GOTO
and is less than 1 or more than 5
then the GOTO is skipped.

    It's rather simple. If you're
skimming past this section because ON
GOTO confuses you, don't give up.
Read it again.

    ON GOTO is your alternative to:

10 GET A$:IF A$<"1" OR A$>"5"THEN 10

20 IFA$="1"THEN150

30 IFA$="2"THEN160

40 IFA$="3"THEN170

50 IFA$="4"THEN180

60 IFA$="5"THEN190


    Imagine if you had 10 branches!

    Note that ON GOSUB works the same
as ON GOTO:

10 GET A$:IF A$<"1" OR A$>"5"THEN 10

20 ON VAL(A$)GOSUB 150,160,170,180,190

30 GOTO 10

    No matter which line is branched
to, the program will RETURN to line
20 and execute any further
instructions on that line (if any).
In this case there are no further
instructions and the program moves on
to line 30. Again, imagine this
routine without ON GOSUB:

10 GET A$:IF A$<"1" OR A$>"5"THEN 10

20 IFA$="1"THEN GOSUB 150:GOTO 10

30 IFA$="2"THEN GOSUB 160:GOTO 10

40 IFA$="3"THEN GOSUB 170:GOTO 10

50 IFA$="4"THEN GOSUB 180:GOTO 10

60 IFA$="5"THEN GOSUB 190:GOTO 10

    I'd call it an improvement. And
if you're using a good RENUMBER
routine, it should have no problem
renumbering your ON GOTO lines.

    Programs like INSTANT MENU,
published on this issue, make the
task of top-down programming quite
simple. Learn to use it and you'll
save yourself many a headache. You'll
also find yourself writing better,
more structured code.

JLJ


 AFTER-NOTE: I have just one caveat
with Jeff's "Top Down" Scheme. The
first step for me is getting the most
elemental code of the progr