BASIC RULES, by Colin Tringham (Vice-President A.M.U.G.)

        [Ed: This fine article is published with the permission of the
        AMiga User Group, and of course, the writer - AMUG meets on the
        2nd Monday of each month at Burwood RSL, Burwood, Sydney, 7.30 pm]

        I learned Basic from books, just as many of you have done. I still
 remember the joy when my first three line program ran, and the
 frustration when I copied a long Basic program from a magazine and just
 could not get it to work at all.

        One thing I have found missing from all the books of  Basic is
 some rules to work by. Here are some that I really do try to follow, and
 some which I wish I had always followed.

        The first item is to ALWAYS make the first line of your program
 a Rem statement. Include in this line your intention, your name, the
 date and the version number. Start with version 1.0 and update this to
 1.1 then 1.2 etc. when you do a minor revision, and to 2.0 when you do a
 major re-write. This way YOU will always know which is the latest version
 of your program. It is best to include a second REM line also showing
 what you have done to the program. I'll show you an example.

        REM HOTSHOT program, by Colin Tringham, 8/7/88. VERS. 1.1
        REM Graphic title routines added 10/7/88

        Second hint:- Arrange your code into a logical manner. Put all
  the DATA items at the very end of the program, and put routines which
 are not used often towards the end of the program too. Your main program
 should really consist of just calls to the subroutines. e.g.

        REM HOTSHOT program by Colin Tringham, 8/7/88. VERS 2.2
        REM Final details added
        STARTPROGRAM:
        GOSUB INITIALISE
        GOSUB MAIN
        GOSUB ANOTHERGAME
        GOTO STARTPROGRAM

        Of course each of those subroutines will probably call lots of
 other subroutines - that's the beauty of Basic.

        Now you have your program running please check through all the
 spelling. Many of the younger members of this group in particular could
 have a spectacular future ahead of them in programming. But if you can't
 spell then your programming prowess may not be well utilised. In
 particular, check for the words THERE (a place) THEIR (Something
 belonging) and THEY'RE (Short for THEY ARE). I have lost count of the
 number of programs where I have seen these few words used incorrectly.
        Now go back and check for correct punctuation. Remember a full
 stop is NOT a substitute for a space. So don't do this.There should be a
 space between these last two sentences. Remember too that you can add
 more spaces after a full stop and comma if you want. An introduction in
 Basic looks much nicer if the instructions are 'justified' - i.e. both
 left and right margins are even as in a newspaper column. You can add
 spaces to the short lines to do this.

        Have a look for 'the errors of one'. The Faery Tale adventure
 is a very good game, but is spoilt by the statement which often occurs -
 'one foes were defeated in battle'. It is not difficult to check if the
 number of wins, foes, etc. is one and to arrange your print statements
 accordingly. e.g. PRINT "You have won "wongames "game";
                   IF wongames <>1 then print "s"
        I know that the above is a small point, but so was the commercial
 program where the programmer forgot to check if the amount owing was
 equal to $00.00 and to suppress sending out an invoice if it was!

        Now check you program for consistency. Have you used the INPUT
 statement somewhere? That input will need a RETURN code at the end of the
 line. If your program uses the INKEY$ statement it will NOT need a return
 code at the end of the input. Make sure your program tells the user
 whether a RETURN code is needed or not or the user may think the program
 has 'hung'. Does your program use the Mouse? If so make sure the entire
 program can be run by using the mouse if possible. Having to change from
 mouse to keyboard to joystick and back is not good practice.

        Now get a friend - or preferably an enemy - to try out your
 program to see if it is crashproof. See what happens when someone inputs
 numbers when an ASCII character is required and vice-versa. Such errors
 can easily destroy your beautifully formatted screen if a REDO FROM START
 message appears when you do not want it.

        By now your program should be in good shape. Add the final
 touches. Choose the best colours (but remember to reset the default
 Workbench colours when you exit the program please). Add large title
 letters (If you don't know any of the ways in which you can  do this
 then ask me and I'll write an article on that subject). First
 impressions count. Make sure your title screen stands out and says that
 this is a program which is above average. If possible think of a name for
 your programs - such as 'Bob Brow ns Bonza Basic Bombproof Programs'.
 Just don't steal MY 'trademark'; My major programs have a title screen
 which reads - 'This program is from the Miracle Software Company - If it
 works it's a Miracle'.

        Beware of the 'Shift key error' It is so easy to hit the Caps Lock
  key without realising it. If your program is expecting a 'yes' or 'no'
 input, make sure that it will cope also with YES, Yes, and yes etc. The
 UCASE$ statement can be handy here.

        A Computer is supposedly an intelligent machine, and hopefully
 you, the programmer are also intelligent. Well, take the time and trouble
 to give your program some intelligence too. Instead of a set statement at
 the end of the program such as 'you win, shall we play another game?',
 try and think of three or four different ways of saying the same thing
 and picking one at random at the end of each game. This does add a nice
 touch to your program.

        Finally see if your program has any frustration factors built
 in. If there are large amounts of data to be READ into the program,
 ensure that the user has something to read on the screen whilst this is
 going on. Looking at a blank screen for even five seconds after the
 program starts can be off-putting. If the Data to be read is really huge,
 try to put something on the screen, read some data, re-access the screen
 and then read more data etc. That way the Computer operator will know
 that at least something is happening!

        To ensure that you do not make typing mistakes when entering
 a program, type all the code in LOWER CASE. WHen you hit the RETURN key
 at the end of each line, all RESERVED WORDS will automatically transfer
 themselves to upper case. This is handy to catch errors such as typing
 'Pirnt' in stead of 'PRINT'.

 Happy Programming - Colin Tringham (phone 957-5539).

XXXXXXXXXXXXXXXXXXXXXXX END OF BASICRULES XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX