 C                                                                 HOUGHTS, ETC.\\ 
\\ 
These are just some of the items I think the discussion group could consider.  I know you must have others.\\ 
\\ 
VERY IMPORTANT THAT WE GET :\\ 
l. YOU\r~05,80\\ 
\P\Q\CPAGE 14.\\ 
\r~05,40\\ 
\K\Q\CNATIONAL AUG CONT.,\\ 
\A\\ 
YOUR IDEAS, THOUGHTS, ETC.\\ 
\\ 
These are just some of the items I think the discussion group could consider.  I know you must have others.\\ 
\\ 
VERY IMPORTANT THAT WE GET :\\ 
l. YOUR IDEAS\\ 
2. SOME PERSON TO TAKE THIS PROJECT OVER & PUSH IT.\\ 
3. THE DISCUSSION GROUP STARTED.\\ 
\\ 
Look beyond your little space, your local group, etc.  There is a whole great big wonderful world out there just waiting for you to take the lst step towards it.\\ 
\\ 
Barry Wilson\\ 
\\ 
EDITOR'S FOOTNOTE.\\ 
\\ 
Readers of this article, must remember that it was written well before ADAMCON 01 took place. I believe that the strong Canadian representation at ADAMCON will serve to show that, not only is there a possible foundation in the United States, for a "national" organization, but there is probably also a similar foundation for an "international" organization throughout the North American continent. I believe that we, as Canadians, should try to participate in any discussions on this subject before the idea becomes too parochial. WHAT DO YOU SAY????.\\ 
\\ 
\CGENERAL PROGRAMMING TIPS\\ 
\A\\ 
This is a modification of an excellent article by Peter Hartzler which appeared in the June AWAUG (Wash.DC area) newsletter.\\
I particularly liked this article as I feel not enough is being written for the beginning programmer and this article gives an excellent approach to some of the problems involved.  I have modified it slightly to attempt to save space & to give explanations as to what each line actually does.\\ 
\\
A good first step in program writing is to WRITE down exactly what you want the program to do, including: what data will be used, where it will come from, what the output will be, and how ADAM will arrive at it's results.  This can be very difficult but once you have this much, the rest of the program design will be easy.\\ 
\\ 
Take a program which takes two numbers from the operator, and divides the first by the second, and then displays the answer.  Also remembering that if the second number is zero (division by zero), then the program should display a message such as "ILLEGAL DENOMINATOR", and recycle to the beginning for another try.\\ 
\\ 
\r~45,80\\ 
\K\Q\A\\ 
\\ 
\\ 
\\ 
AT THIS POINT, WHY DON'T YOU TRY TO WRITE SUCH A PROGRAM BEFORE FINISHING THIS ARTICLE.\\ 
\\ 
Peter Hartzler continues that once you have decided just what you want the program to do, your next step is to design the structure of the program, which means setting down what the machine will do first, next, etc. until it completes it's run of the program. If your program uses many branches or loops you may find flow charts to be an aid.  Another approach is to write out the program structure in outline form (this is also called pseudocode).\\ 
\\ 
START\\ 
GET NUMERATOR\\ 
GET DENOMINATOR\\ 
IF DENOMINATOR = 0\\ 
DISPLAY "ILLEGAL DENOMINATOR"\\ 
GO TO START\\ 
ELSE\\ 
COMPUTE RESULT = \\ 
NUMERATOR/DENOMINATOR\\ 
END IF\\ 
DISPLAY RESULT\\ 
END:\\ 
\\ 
You may go through several revisions before you are finished with the preliminary program design.  Also when you go back and modify your program you can use the design as a reference to see just where you need to make what changes. \\ 
\\ 
As you design the program, look for operations which you need to do more than once.  Rather than writing these out each time you need them, you can save a lot of trouble by writing the routine once and calling it (GOSUB in basic) from the places you need it.  This will save time and better if there is an error in a subroutine, one set of changes will be all that is needed, rather than changing it throughout the program for each repetition of that operation.\\ 
\\ 
The strategy of using a section of code more than once, as a subroutine is key to the concept of modular programming.  It also makes debugging programs a lot easier.\\ 
\\ 
Peter Hartzler then gives these thoughts on variable names.  There is really no excuse for using only single letters for variable names.  Most interpreters allow quite a few characters in a variable name (SmartBASIC does), and you should take advantage of this.  If you write code which has lots of x's, y's and z's and other sorts of alphabet soup, it may run fine but is very hard to read, especially after it has set on the shelf for awhile and you forgot what "q" represents.  Avoid cryptic variable names.\\ 
\\ 
iting the routine once and calling it (GOSUB in basic) from t
