For those using the compiler versions of BASIC, many people miss taking good advantage of its features available to support modular programming, though.  In part, I think this is because of the informal way that many people learn Quick BASIC.  In part, it's simply because you can do a lot of programming in Quick BASIC without worrying about it.  But at some point, when writing large, complex programs, almost everyone begins to encounter difficulties that will push them into thinking along modular programming lines.

For those using QBASIC alone, it doesn't support writing BASIC code in separate modules. However, for those interested in getting one of the Microsoft Quick BASIC compilers (or their Professional Development System 7.1 compiler) and trying out the idea of writing modules, QB Cafe offers several versions, freely available, at:

QBCafe Compiler Download Page

I have NOT downloaded any of these files or bothered to check them out against my own personal versions I own. However, I've no reason to believe there is a problem with them. I believe it is the case that Microsoft understands the value in allowing people to continue learning from and using these compilers and is accepting this site on those grounds.

What is a module?

The term module has several common meanings. It's only by listening to the context that we can understand exactly what someone means, using it. Sometimes, it's just a synonym for a file. Sometimes, it's not quite the same thing.

The simplest meaning is that a module is a source code file -- nothing more than just another way to say the same thing.  Maybe it just sounds better to call it a module, than to call it a file. But I've seen cases where module was used for exactly that and nothing else.

Sometimes, this simple meaning is broadened a bit to refer not only to the source code file itself, but also to imply an associated declaration file. These declaration files are used by other modules when they need to access exported features of the module being discussed.  Each of these modules are usually compiled separately and then linked together into a final program.

Perhaps a broader definition of module is any compilation unit which can specifically import symbols external to it and specifically export selected symbols to other compilation units, as well. For some languages, several such compilation units can be inserted into a single source code file. In Quick BASIC, a file is always compiled as exactly one module so it's common for Quick BASIC programmers to conflate to two concepts.

Professional programmers have learned a lot over the years about writing code. Modularization is one of those areas worth knowing something about. Some of these lessons you'll learn on your own, just because you have to walk the same paths everyone does. But some aren't quite so obvious until someone spells it out.

Here's a Microsoft web site on the details of making QB modules:

QuickBASIC Modules

The QuickBASIC development environment and the compiler have different limitations on amount of code and data they can handle. In other words, it's quite possible that your code won't run under the QuickBASIC editor/environment but will run just fine if you break the program up a little and link it all back up, later. This page discusses some of the details.

QBASIC Modules

For the QBASIC interpreter, you've really no choice. It all needs to fit into one file you can load up and run. But for the QuickBASIC compiler, there's no problem in writing and using several different source files that are combined into one final program when you are ready. But why do it at all? Why not just pile everything into a single program file?

One answer is that sometimes there is a collection of routines that are useful for more than one program. For example, I've written some routines to help parse and evaluate various mathematical expressions and I've written some routines to manage editing text with special key handling. I may want to simply use these again in some other program. And if I enhance or improve them in some fashion, it would be convenient if I didn't have to go pasting their code into program after program, each time I change them. Placing the code into a distinct module allows me to simply include that module into any program I'm working on and I can count on that program getting the right set of well-tested and well-designed routines. And if, later on, I improve that module then all I need to do is recompile a program without any editing or changes to it and I'll automatically pick up the latest features.

Writing a module is easy. But there are a few useful rules to the process. One is that each module I make is actually two files. I write my code into one with a .BAS extension and I write my DECLARE statements for the subroutines and functions into another with a .BI extension. Then, in the .BAS module I use a $INCLUDE statement to include that .BI file, before any code. Then, in each program or other module I write that uses this module, the .BAS file I'm working on also uses a $INCLUDE statement to include the .BI file, as well. This way, each source file includes the necessary DECLARE statements so that the functions and subroutines can be called from within that source file.

There are a few other important details. When you break up your source code into modules, other modules cannot access variables in the DIM SHARED statements of a particular module. So, if you share variables with your various routines that way, you'll have to find another way to do it. Sometimes, this means writing even more routines in your module so that other modules can call those routines to either modify or access those values. Sometimes, this may mean using COMMON, instead.

I think that if you experiment with the idea a bit and get familiar with it, you'll find that you use the concept more and more. If you are interested in seeing some modularized examples, I've prepared three ZIP files you can look at. They are all based on my web pages on parsing. These examples all parse and execute algebraic mathematical expressions and do exactly the same things. The only differences are in the modularization. They may help in seeing how.

EQ_10.BAS or EQ_10.ZIP

This one isn't modularized, at all. It's all in a single .BAS file. It has one, big advantage over the over the version below -- it runs well using the QBASIC interpreter. This can be an important advantage.

EQ.ZIP

This example converts the above file into five parts -- the main program in EQ, the expression analyzer in PARSE, the variable handling in VARIABLE, the atom table (for saving unique strings) in TABLE, and the hashing function in HASH. Each of these modules (except for EQ, itself) are useful routines for other programs, too. The hashing routines are very useful for other purposes, as is the atom table management. The downside with this modularized version is that QBASIC cannot run it. It requires QB or QBX or VBDOS in order to load it.

Feel free to email me.

Last updated: Sunday, July 18, 2004 10:53