Introduction

Given the desirable attributes attained by reusing software, it is important
to define the concept concisely. This is especially true given the wide
range of interpretations assigned to this seemingly self-explanatory pair
of words.

Software reuse is concerned with the ability use a source code component
in more than one context without changing the component.

Sounds simple enough, right? The problem comes with the "without change"
restriction. Not only does this mean that the file containing the source
code may not be changed, it also means that the file cannot be moved, copied,
renamed or conditionally compiled.

Namespace Changes

The act of moving or renaming a source file by definition affects the location
of the file within the filesystem namespace. Such changes can force changes
to dependent files. These dependent files include build environment files
and other source files.

Build environment files include makefiles, environment variables, and
build scripts that specify the location of files to be used within a project.
For example, header include paths or paths specifying which source files
need to be compiled for a given application.

Dependent source files may also be affected. For example if it is a
header file whose name or location is being changed, all source files that
include that header file must be modified to refer to the new location/name.

Moving files that have only one or two other dependent files is reasonably
trivial. However, once a source code module has many dependents (a property
that is highly desirable in a reuse environment), moving or renaming
a file becomes prohibitively time consuming. Thus, the organization
of the source code repository is extremely important when reusing software.

Copying Files

Copying a source code module leads to increased maintenance costs.
If a defect is found and corrected in one of the copies, the change must
be propagated to all of the other copies. The cost of this maintenance
grows with the number of copies. Again, given the desirability of reusing
a module as many times as possible, this scalability issue is quite important.

Unfortunately, copying a source file and using it in another context
is a common practice within the software industry, that is frequently termed
"software reuse". However, since this technique does not meet the standards
defined here for software reuse, the terms "port" or "copy"
will be used to refer to this technique.

Conditional Compilation

It is a time honored tradition, especially in the world of C/C++, to use
the pre-processor's conditional compilation facilities as a means to reuse
software. This is this yet another abuse of the C/C++ pre-processor. Aside
from producing an unreadable rat's nest of code that very much affects
the maintainability of the source code, it only results in the reuse of
the file-name itself.

Like any tool, conditional compilation has its place. For example, as
a mechanism for ensuring that a file is included only once for a given
compilation unit. However, for the purposes of software reuse, conditional
compilation is usually a sign that there is a need to examine the source
code for abstraction opportunities. Typically, interfaces can be defined
and the appropriate implementation used by the project at compile and link
time rather than during pre-processing.