Through work I get a number of computer related magazines, either directly to me or ones that are received by the office. This gives me a chance to scan articles on a variety of subjects, of which some I find applicable to my computing. I like to try to apply different programming concepts I glean from these articles to my personal programming. Not being a developmental programmer at work ( I mostly hack a bit in Perl, C Shell, Awk, or HTML.), I am not able to professionally utilize articles on Software Engineering, Object Oriented Programming, Computer Aided Software Development, etc. Issues dealing with programming teams do not apply well to a single programmer.
While reading one magazine, I read a series of articles on Software Reuse. Software Reuse has been touted as one of the key benefits of Object Oriented Programming. Software Reuse is the concept that the code you write can be easily used by another programmer. This concept has been well used in the form of libraries consisting of “canned” functions and procedures. A good example is the standard library of C, which is a number of “reused” routines. Proponents of OOP have claimed that OOP can take software reuse beyond just the reuse of functions and procedures. Something not believed by the author of the series.
He stated that developers have a tendency to develop from scratch for three reasons:
- The initial cost of investigating someone else’s work is often high.
- There is uncertainty as to whether the code will work.
- There is uncertainty as to who will fix the code if it does not work.
This sort of thing is still happening. There is so much source code available on the Internet or through CD-ROM, but many programmers still write the simple stuff from scratch.
After reading the series, I pondered on how software reuse could be utilized in my programming. Since, by default, I almost always write in Structured SuperBasic I thought about how reuse can be implemented using it, especially in comparison to straight SuperBasic.
As I mentioned above, the primary way to implement software reuse it in the reuse of procedures and functions. These procedures and functions should be written as solid little boxes of code. I mean solid in that they should be well tested and error free. I mean little in that they should not try to accomplish too much. They should be designed to perform one task well.
Each procedure or function can be stored in a separate file and pulled into your code by using the #INCLUDE feature of SSB. Implemented this way, the actual code of the routines do not clutter up your “real” code and they can look like a library routine.
You can MERGE code in straight SuperBasic, but with line numbers you always have to worry about any MERGEd routines having the same line numbers of others. With SSB, this problem goes away.
With the proper use of #INCLUDE, the C language concept of static variables can be implemented. Static variables are those variables used by routines that are “remembered” between times the routine is called. In a way static variables behave like global variables.
When storing a routine in a separate file, one would normally just have the function or procedure code in the file. By having one or more variables written in the file, but outside the definition (scope) of the function or procedure, these variables become global or static. This is only true if the #INCLUDE statement is used outside of function or procedure definitions. An example is this:
var = 0
DEFine FuNction sum( in_var )
var = var + in_var
RETURN var
END DEFine
Now the value of var will be retained between calls to the function sum(). Try to name your static/global variables with names that are unlikely to be used in the main program. If someone else #INCLUDEs this function and used the variable var in their program, the effect is totally lost and the function will not work.