Design and Scope

As I have stated several times, you can have as many modules in your project as you need. However, is it wise just to throw any procedure on any module without thought? Of course not!

Here is a design point: each procedure should perform one specialized task. For instance, in this chapter, we have used an example of a function whose only job is to concatenate a last name and a first name. It is not unusual to see that. By doing it that way, you end up with code that is easier to manage and debug. It also makes the procedure reusable. For instance, anytime in the project you need to concatenate, you can call the same procedure. While this will not add to memory “overhead,” your project could end up with many procedures. In programming parlance, the term overhead is the amount of resources something uses.

You have also seen that a procedure rarely exists on its own. As stated at the beginning of this chapter, in most projects, it is not unusual to see procedure A call procedure B, which in turn calls procedure C, and so on.

While there are no hard-and-fast rules, you should try to group procedures in the modules with their dependence in mind. For instance, you may want all the procedures for formatting names in one module, while the procedures to do date calculations are in another module.

In practice, you preface procedures with the keywords Public or Private. Public means that the procedure can be accessed by another procedure in another module. Private means that it can be accessed only by procedures in the same module. Again, deciding which procedures to make public, and which to make private, is a design issue with no hard rules.

Many times you will make only one or two procedures public. In programming terms, these procedures serve as the module’s interface. In other words, this is the controlled access point to the module from other modules.

Variables have a scope also. The term scope means who can see it. As you saw earlier, a variable within a procedure normally can only be seen within that procedure; when the procedure’s job ends, the variable and its contents fade into the sunset. We say that its scope is local to that procedure.

Again, to summarize, a local procedure has a lifetime of the procedure that it is located in.

Next, I will be talking about two other types of variables whose lifetime is outside of a procedure.