---------
Face Lift
---------

        I tell you what, I look back on my older programs. and I have NO
idea how I was able to write them. All the lines are against the left 
side. I used 1 letter variables for EVERYTHING. And I used a crap load of
GOTOs. I can't write them, let alone try and upgrade them to use some
of the speed methods I talked about last issue, or 256 colors. I'll tell
you what folks, go out and learn another computer language like C++, it
will help alot. I'm taking it at school in AP Computer Science. I learned
so many ways to increase the power of my code. And the style you use can be
adapted to other programming languages. 

        I started using Qbasic in March 1997. Before that I have mastered
TI-BASIC, and briefly used GW-Basic. Coming from TI, I NEVER used DO loops.
I used a ton of GOTOs. Also, I couldn't indent on the TI for readability when
dealing with nested statements. Nested statements are when you have FORs, 
DOs, IFs, WHILEs inside other FORs, DOs, Ifs, WHILEs. It is very hard to 
follow in what "level" so to speak, you are in. Observe the following:

if x%>100 then
if len(key$) then
for a%=1 to 70
hit=round%(a%*7)
next
else
do
for x=1 to 80
if x=pht% then 
beep
exit do
end if
next
hit=hit-1
loop
end if

        This doesn't do anything. I just made it up. But it is very hard 
to tell which lines of code are executed under what conditions. You can't 
easily see which IFs go with which END IFs, DOs with LOOPs, or FORs with 
NEXTs. Now, if you will look at the next example you will see a simple way 
to see what matches with what, and you will understand what I mean about 
"levels"

if x%>100 then
 if len(key$) then
  for a%=1 to 70
   hit=round%(a%*7)
  next
else
  do
   for x=1 to 80
    if x=pht% then 
     beep
     exit do
    end if
   next
   hit=hit-1
  loop
end if

        That is much easier to read. When you write programs that do alot of
decision making, this will become a problem unless you level your code. See
what I said about other languages influencing you. TI-BASIC caused me to
code like that, and It took me over a year and a half to break the habit.
also, COMMENT THE HELL OUT OF YOUR PROGRAMS. Comments add space to your 
.BAS file, and that's all. If you compile, the comments are ignored by the
compiler. Comments are a big help. The following is a little bit of Code
that AcidOS 4.3 uses:

OPEN path$ + "applist.sys" FOR INPUT AS #1

'The next block of code reads from the file "AppList.sys" the name of
'a file. It closes any open files in the range 101-(100+NumOfGroups%)
'and then opens the file as that file number

FOR X% = 1 TO NumOfGroups% 'for all the Groups...
 E% = 100 + X%             '101 thur 100 +NumOfGroups% RESERSVED     
 CLOSE E%  'make sure file E% is closed
 LINE INPUT #1, Appfile$   'Open the Group file
 OPEN path$ + Appfile$ FOR RANDOM AS E%
NEXT
CLOSE #1

TIMER ON                'resume timer control

        The comments are clear, and tell what is going on. Don't make them
too long, 3-4 lines at the very most. Also notice how I broke the code into
Chunks. Chunking is another great way to help make you programs more 
readable, by using blank lines to group chunks of code. Not using comments
can be horrible. When I was writing AcidOS 3.0, I got stuck about 60% of 
the way through. I left it for about 4 months. When I came back, I had no 
idea how the basic Icons/applications were detected and loaded, let alone my
original problem with minimizing application to simulate Multi-tasking. You 
can read my article of about AcidOS later in this issue. Anyway, I had to 
re-write  the whole thing from scratch. Comments allow you do keep hundreds 
of files and always be able to figure out what is going on in any of them 
anywhere. If you think this sounds stupid (and believe me, I did back when 
I started), it is just because you are not writing very complicated or 
long programs yet.

        Another way I keep track of what is going on inside my programs are
with variable and Function/sub names. In the last 2 issues, you may have 
noticed in my examples, I have weird names. It's to help YOU. Make big names 
for your variables to describe what they are. Don't use "n%", use 
"NumOfGoodsInStock%". Always use a mixture of UPPER and lower case, so you 
can read the name quickly inside of "switchisactive%", you see 
"SwitchIsActive%." 
        
        People may tell you to use "."'s in your variable names. I disagree 
because "."'s are mainly used when you declare your own data type using TYPE. 
If you don't know what I am referring to don't worry. TYPE is kind-of 
advanced, so just get in the habit of NOT using "."'s in your names. Note 
that your variable names in your .BAS file are completely different from the 
variables names in the complied .EXE. The compiled names are picked by the 
compiler, and are very short, so the length of the names you pick doesn't 
affect the size or speed of the compiled program.

        Lastly GOTOs. Everyone says they are bad, and they are. It is easy
to fall in the habit of using them all the time. As you program more and 
more, you will find ways around them, by using DO :LOOPS. Sometimes you
do need to use a GOTO. That's alright. I recommend having a notepad next to
you and keep track of all the label names you use, so as not to mix them up.
Also, I would put a comment line " '*********" both above and below the
label so it is easy to see. People's biggest complaints with GOTOs are that
it is difficult to find the matching label for it. People also claim that 
GOTOs show poor programming skills, and don't have to be used. Well, here 
is the trade off. It is POSSIBLE to write a program without any GOTOs, but 
it is nearly Impossible. You would have a ton of DO LOOPs. and need to use a 
lot of variables as "flags" to exit the DO LOOPs. These extra variables make 
your program bigger. So, use GOTOs, just not a lot.


--------------------------------------------------------------------------------
This tutorial originally appeared in the QBasic Developers Forum, Issue #3.
This was written by Lord Acidus.