8-bit Software Disc Magazine (c) Duncan Webster 1991
Address: 7, Ashdale, Thringstone, Leicestershire LE6 4LW
Issue 12 May 1991
MEMBERS ARTICLES
User: <unknown> - if this is your article, then thanks!
HOW TO PLAN AND CONSTRUCT PROGRAMS.
Upon examining various issue discs, the quality of the software is
good, but on more than one occasion, the actual coding of the program
has been very poor. Poor program structuring 99% of times leads to
confusion when coming to update or improve software at a later date.
The following article provides some advice on how to plan a program
and how to go about presentation .....
Tell tale signs of bad programming ....
1> The constant use of UPPER CASE LETTER ONLY. This normally means
that the programmer just cannot be bothered to press the SHIFT key
once in a while.
2> General screen layout. You can normally tell how much thought
has gone into the design of a screen. It is best to use a window
system so the the user can see their status at a glance ...
Example screen layout (mode 0)
------------------------------------------------------------------
: :
: --------------------------- -------------------- :
: : : : : :
: : : : : :
: : Status : : : :
: : Window : : Other : :
: : : : : :
: : : : : :
: : : : : :
: : : : : :
: --------------------------- -------------------- :
: :
: ----------------------------------------------------- :
: : : :
: : : :
: : Command Window : :
: : : :
: ----------------------------------------------------- :
: :
------------------------------------------------------------------
The STATUS window should contain the players/users status. This
window should be updated at the end of each turn/phase/transaction.
The COMMAND window should be defined as a text window and should be
the place for the computer to ask questions and where answers should
be typed in.
The OTHER window should be where the game or activity status would be
displayed (ie. cost of assetts etc etc.).
I personally find mode 0 the best screen mode to use for this type of
thing. BBC BASIC's DIM statement should also be put to good use when
there are a lot of related variables within a program. To take an
example ... DIM assets$(20)
assets$(1)="CASH"
assets$(2)="CHEQUE" etc...
Short article eh? But is DOES bring home a good message to all would
be programmers. The golden rule is to PLAN your program structure,
and decide what the program is to do from beginning to end BEFORE you
even sit down at the computer. Only when you have an exact idea of
how the program is to appear should you attempt to code it. When
coding your program, you should use MEANINGFUL variables (ie. Cost$,
start%, Value%) so you do not get lost. Although this IS greedy on
memory, there are many program variable crunchers around, that will
strip all your variables down the the bear minimum when you have
finished. However be sure to keep an uncrunched version for future
expansion.
If you have submitted software to 8-bit in the past, then I would very
much like to know exactly how you program a piece of software from
beginning to end. What are the approaches you use? What do you do
when you run into problems (apart from panick?) - can anyone give me a
full account of contructing a program from start to end? I await your
comments ...