QBSUB.TXT -- Personal comments about using QuickBASIC25 June 86
by David L. Poskie (608) 274-9560
7118 Raymond Rd. Madison, WI 53719

Introduction:
This note accompanies QBSUB10.ARC, a series of utility subroutines
to be used in MS QuickBASIC programming. I hope they are useful
to other programmers, and that others who are not using QuickBASIC
will look at the code. It's not PASCAL, but it's not the old
BASIC, either -- it's QuickBASIC !

>> Overview:
First, I do what I do quite well, but I am not an expert at using
or understanding QBasic (bear with this shorter form). I hope others
who know more will help me with their criticism and suggestions.
This note is not only about QBSUBnn.ARC -- it is about QBasic and
some of the other programs I am using. First, there is a file named
QBSUBDMO.ARC, which contains many programs that demonstrate using
the subroutines in QBSUB10.ARC. These require QBSUB10.ARC. Then
there is a file of my utility subroutines, QBUTIL.ARC. In here are
two of my utility programs, RLIN.ASC & FOX.ASC. RLIN is a modified
version of Microsoft's REMLINE.BAS, which is furnished with each
copy of QuickBASIC. RLIN removes unnecessary line numbers from
conventional BASIC programs. In RLIN, program format and variable
names have been changed to be compatible with my subroutines files.
FOX is a program I've written to break down conventional BASIC
programs, formatting them in the looser style permitted by QBasic.
You don't have to be a QBasic programmer to find a use for FOX. It
can display any ASCII-saved BASIC program in a looser format, to
help you understand what is going on. FOX uses the subroutines in
QBSUB10.ARC. Finally, there is QBX.EXE, a program written by
Vernon Buerg, et.al.. QBX takes an unlined QBasic program and adds
line numbers, then produces a cross-reference of the program. The
combination of RLIN, FOX, & QBX are my mainstay for converting
BASIC programs to QuickBASIC, and vice-versa. Yes, there are times
I want to work on a QBasic routine in the interpreter. For short
hacks and experiments, it is often much faster in interpreter than
to go through editing in WordStar, compilation with BASCOM, and
linking with LINK. Troubleshooting is also often best done with line
numbers. To be able to work in interpreter or compiler gives a great
deal of flexibility and power to QBasic users.

>> My Personal Style of QuickBASIC programming:
I like working with QBasic very much. The freedom of layout can
result in code that is far easier to write and to understand than
code in standard BASIC. The ability to use long variable names also
helps, provided the names are well chosen. Take a look at my time
simulation program -- SIMTIME.ASC. I think it is beautiful. MNULIN
is pretty, too. None of these are as good looking as the best PASCAL
programs I've seen, but they are a big improvement over BASIC.

I would really appreciate looking at how others code in QBASIC.
The rules are rather open; much of my form comes from my own
preferences for layout. Then there is the naming of variables and
lines -- that, too, is my invention, borrowing heavily from my
assembly language preferences. My preference is to comment in
mixed case, and to program in CAPS. But QuickBASIC allows you to
write code in lower case, the preference of many PASCAL and C
programmers. Notice how heavily you can comment the code and how
flexible you can be in where you place the comments. A short time
ago, I programmed completely in upper case, but have grown fond of
naming my variables and procedures in mixed case. The compiler
is blind to case in these instances, though, but it aids readability.

I have my own convention for setting the file extensions;
I use BAS to designate a program that will run in BASICA, ASC to
designate a program that will run only in QuickBASIC, and SUB to
designate a QuickBASIC subroutine that must be $INCLUDE'ed in the
calling program. In general, ASCII-saved BAS files will also work
in QuickBASIC, but many BASIC programs need modification. About the
only thing QuickBASIC will not do is BLOAD, but CALL seems to work
fine in place of it.

>> How I convert other's BASICA programs:
First, I strip out unneeded line numbers from an ASCII-saved
conventional program. For this I use RLIN. After filtering through
RLIN, I immediately try to compile the program with BASCOM. This
normally pukes out a bunch of errors that I write down. RLIN
sometimes removes line numbers that are needed (I can't figure why).
BASCOM catches this and, at this time, it is relatively easy to
go into the file and replace the mistakenly stripped line numbers.
Then I make the changes noted from the compiler error messages. It
gets a bit hazy here, but I'm working to the point where the program
will compile without any error messages. Once I get here, I do
something that will make it all much easier. I run it through FOX,
my QBasic program that will take what came from RLIN and strips out
the executable statements, one per line. Then I begin the process of
formatting and commenting the code. I have taken very complicated
programs written by others with no comments and made sense of them
with this technique. You'll be surprised how much more understandable
the code is when it is spread out and formatted. Then I begin to
replace line numbers with sensible names, mebbe changing variable
names in the same way. I start separating out all the subroutines,
getting them tight and pretty, finally putting them in the best spot.
Then I begin to search the code for chances to make more subroutines,
eliminating redundant code. While I'm doing this, I'm looking to
speed up and simplify the code, moving and changing it, eliminating
variable names that could be combined in another general purpose
variable. This takes experience, and I've made a lot of mistakes to
have earned the experience. It's fun, though, like working a
crossword puzzle. By this time, I am familiar enough with the code
that I am enhancing it -- searching to improve its feel, function,
look, performance. Always learning from what someone else has done.

>> How I troubleshoot in QuickBASIC:
If I run into any snags, I can use QBX to reenter linenumbers and
to cross-reference. Then I can put the line number version back in
interpreter, use TRON, or other debugging schemes I've devised.
Here's one I use -- I have this code in a file:
'Debug
TempX = CSRLIN : TempY = POS(0)' Save current position
LOCATE 25,1' Go to bottom line
PRINT " >> Put the questioned variables here <<";
LOCATE TempX , TempY' Return to current position

When I have a roadblock bug, I insert this code, bracketing the
trouble area. This gives me a readout of the questioned variables on
the bottom line of the screen without messing up anything else.
It is more difficult to trace code without line numbers. Sometimes
I'll go into the code and simply put line numbers in front of each
line in the subroutine (by hand). Other times, I use QBX to put
line numbers throughout the program.

>> Epilog:
There are things I've yet to explore:
Calling assembly language subroutines
Using MAKE to handle compilation
Possibly setting up LIBS of subroutines for MAKE
The unknowns that YOU will tell me about

ENJOY . . .

David L. Poskie Madison, WI

>>>>> Physical EOF QBSUB.TXT