Implementation - Software Engineering: A Hands-On Approach - page 179

Use consistent and meaningful variable Names: This implies that the pro-
grammer developing a module is merely the first of many other programmers who
will work on module. It is counterproductive for a programmer to give names to
variables that are meaningful to only that programmer; within the context of
software engineering, meaningful means ''meaningful from the viewpoint of future
maintenance programmers''.
Self-document the code: The important point is whether the module can be
understood easily and unambiguously by all the other programmers who will read
the code. Prologue comments are mandatory in every single module. The mini-
mum information that must be provided for every module is: module name; brief
description of what the module does; programmer's name; date when the module
was coded; list of module arguments; list of variables names; known faults if any.
Use parameters: There are very few genuine constants, that is variables whose
values never change. All such apparent constants should be treated as parameters.
If a value should change for any reason, this change can be implemented quickly
and effectively.
Readable code layout: Indentation is perhaps the most important technique for
increasing readability. It also helps to clarify which statements belong with which
block. Another useful aid is the proper use of blank lines.
9.9 Code Reuse
Reuse refers to using components of one product to facilitate the development of a
different product, with a different functionality. A reusable component need not
necessarily be a module or a code fragment—it could be a design, a part of a
manual, a set of test data, or a duration and cost estimate. There are two types of
reuse, opportunistic reuse and deliberate reuse. If the developers of a new product
realize that a component of a previously developed product can be reused in the
new product, then this is opportunistic reuse, sometimes referred to as accidental
reuse. On the other hand, utilization of software components constructed specifi-
cally for possible future reuse is considered to be systematic reuse or deliberate
reuse. A potential advantage of systematic reuse in comparison to opportunistic
reuse is that components specially constructed for use in future products are more
likely to be easy and safe to reuse; such components generally are robust, well
documented, and thoroughly tested. Maintaining is made to be a much easier task
with systematic reuse but, it can be expensive (Schach 2007 ).
9.10 Integration
One approach towards integration of the product is to code and test each individual
code artifact separately, followed by linking together all the code artifacts and then
testing test the product as a whole. There are two common difficulties with this