Using True BASIC Libraries

By A. Michael Gildersleeve

You're writing a program, and suddenly you get the uncanny feeling that you've written this code before; in fact, it seems that you've written it hundreds of times.

No, you haven't discovered the fourth dimension or entered the Twilight Zone. You can't even blame it on something as mundane as déjà vu or flashbacks to past

lives. Most likely it's true; you are indeed writing the same code you have written ten, twenty, even a hundred times before. Why get bogged down in mindless

repetition, when there is an exciting alternative?

Modern structured programming languages such as True BASIC offer mechanisms designed to help programmers avoid the tedium inherent in writing repetitive

code and get on with the interesting part of their project. Using True BASIC's libraries, you can create collections of the tools that you use most frequently in your

programming and have them readily at hand whenever and wherever you need them. And best of all, you can create and collect the tools that you need, not those

that someone else thinks you need!

As an example, let's say you've written a financial calculator to determine things like the future value of an investment and the monthly payment on a loan.

Sometime thereafter you wrote an editor to deal with text files. Now you have decided to write a full-fledged accounting package. As you design your accounting

program, you realize that you already wrote code that did the majority of the necessary calculations when you wrote your calculator, and a lot of the file handling

routines you now need are included in the editor. If you structured these earlier programs using libraries, you're in luck. All you need to do is let your accounting

package know which libraries the routines are in and then use them. Think of the time you've saved!

If you've never used True BASIC's libraries before, you'll be glad to know that as a practitioner of structured programming techniques you already know how to

create these tools.

As you design your programs, you probably employ some variation of the divide and conquer approach to problem solving. This is the method whereby a complex

problem is broken down into component problems, which are presumably easier to solve. Each of these component problems is then evaluated; if its solution is

readily apparent, then it is left alone, otherwise the divide and conquer approach is applied to it as well. Eventually, you are left with a collection of easily

manageable sub problems that you know how to solve. If you can solve all of these sub problems, you can combine their solutions in a way that solves the original

problem, regardless of its complexity.

Applying the divide and conquer technique in a structured language such as True BASIC generally involves writing routines. Each routine embodies the solution to

a single sub problem, and the routines - used in the proper sequence - form a solution to the primary problem. If you adhere to this methodology, you should wind

up with a routine for each sub problem.

If you have written a routine to solve each sub problem, then your programming job should become easier with each project you complete. Since many of the sub

problems you encounter will be similar from one project to the next, in theory you should be able to use the routines that solve them in several different programs.

Unfortunately, there are many programmers that don't fully realize this. They recall having written the same code previously, but they don't remember exactly

where. Or they remember having written something similar in an earlier project, but they're using a completely different set of variables in the current program and

consider it to be too much trouble to adapt the earlier code. These are the programmers that fall prey to the frustration and boredom of writing the same code a

hundred different times in a hundred different ways. And the annoyance is compounded by the realization that there has to be a better way!

Avoiding this pitfall is what True BASIC libraries are all about. Properly organized and applied, libraries can virtually eliminate boring, repetitious work. But you

don't get something for nothing in this world, and useful libraries are no exception.

The process of creating a library in True BASIC is actually quite simple. Select the routines that you want the library to contain and move them into a new file

using the True BASIC editor. Move the cursor to the line before the first routine begins and type the keyword EXTERNAL. Then simply save the file with a name

that makes sense to you, and you have a library.

Although these steps are all that is needed to produce a legal True BASIC library, the process of creating and maintaining a useful library is significantly more

involved, in much the same way that writing a good program is much more complicated than writing one that just runs. In the rest of this article, you will find some

suggestions to assist you in your quest to create quality libraries that will be useful across a broad range of applications.

Building a quality library begins with designing quality structured programs. When you are designing a program, evaluate each sub problem and its associated

routine carefully. Analyze them in terms of their potential for general application. Some sub problems are very specific to the solution of a particular problem, and

their associated routines are not likely to be of use elsewhere. Other sub problems are more general, and the routines which embody their solution are quite likely

to come in handy when working on other problems. As you shall see, it is often more difficult to write a routine for inclusion in a library. Therefore, it is not

advisable to invest the time necessary to include all your routines in a library, "just in case." Instead, invest as much time as necessary customizing those routines

which seem to have a more general applicability for use in your libraries.

When you are designing a routine that is destined for a library, remember that True BASIC considers all library routines to be external. This means that such

routines are only able to communicate with their caller via their parameter list; all other variables used in the routine are considered local. (Functions and modules

provide some important exceptions to this rule.) If you design a routine as internal and it relies on global variables, it will run but produce invalid results when

moved into a library.

You should also make every effort possible to generalize the routines that you write for libraries. If you do not, you will likely spend a great deal of time

"tweaking" your library routines to get them to work in a particular program. Remember that libraries are intended to save you work, not create more!

Writing generalized routines is not easy for many programmers, and it often involves a lot of extra work. It often helps to design each library routine as a separate

program. Use variable names that are meaningful in the context of the routine rather than the main program for which it is being designed. Check each input

parameter for validity, much as you would a user's input. Be alert for sources of common errors and use error handlers to intercept and correct them whenever

possible. And don't hesitate to add flags or error codes to the parameter list as necessary. Primarily, you should program a library routine as defensively as

possible, because you can never predict all the situations in which it may be used.

Just as you cannot predict how a routine may be used, you can never predict how long it may be before you need it again. It pays to be especially attentive to your

programming style. The greatest routine ever written is useless if you can't figure out what it does or how it's used! Using comments and descriptive names is

vitally important to the future usefulness of your routines, and each routine should be fully commented, including a description of each parameter and any side

effects or error codes. In fact, many programmers begin each library with an extensive comment section listing and summarizing each routine that it contains.

Creating good library routines does not automatically guarantee good libraries. It is also important to organize your libraries logically. Since True BASIC places

no limit on the number of libraries that a program can employ, there is no reason to forfeit logical library organization. Create as many library files as you feel are

necessary to organize your routines. Most programmers organize their libraries according to functionality. For instance, one library may contain routines that deal

with files, another may contain graphics routines, and still another mathematical functions.

When you have completed a library file, you will most likely want to compile it and use the compiled version in your programs. This will eliminate the need for

True BASIC to compile those routines every time you run your main program, and result in a quicker overall compile time. If you use this method, however, you

should be sure to retain the uncompiled source files for use in maintenance, expansion and improvement.

Don't forget that quality takes time. But if you invest your time in the careful creation and organization of your libraries, you should never have to waste your time

writing boring, repetitious code again!