tions for names of variables. Others concern recording information in comments
for the reader to understand how a program is designed and why. All are equally
important; a chain is no stronger than its weakest link.
It is important to follow good programming conventions all the time. Taste
and care are not things that you can turn on and off at will; either you have these
qualities or you do not. So, right from the start, be disciplined and try to learn and
practice good programming style.
Programming style refers not only to the presentation of a program but also
to the way one goes about programming. Two people may end up with essentially
the same program, but how they got there might be totally different. One person
may use a disciplined, effective style, which took two hours; the other may have
required fifteen hours because their ineffective programming style led to a pro-
gram with many bugs, greatly increasing the testing and debugging time.
Below, we give some guidelines for programming and discuss them.
Following these guidelines will reduce the time spent programming and, more
importantly, the time spent testing and debugging because fewer bugs will be
introduced into programs.
Guideline 1. Specify a program segment before developing it
The following guideline makes sense to most people:
1. Do not try to solve a problem until you know what the problem
In programming, this guideline is expressed in several ways. For example:
1a . Write a clear and precise specification for a method before
writing the method.
This specification must include a description of all parameters of the method.
Also, if a section of code is long and complicated:
1b. Use statement-comments to make code appear short and man-
Bugs creep into a program because you forget precisely what a section of
code is supposed to do and you end up using it in a different way than was intend-
ed. Having a precise specification relieves you of the need to remember and thus
saves you from making the error. Specifications also save time during the devel-
opment process; when using a method, you have to read and understand only the
specification and not the method body.
We use the program of Fig. 13.1 to see how following guideline 1 could have
helped. We want to call method numberOfPrimes , but we forget what range of
integers it investigates. A hurried glance at the method body might give us the
idea that the range is 2..103 , but that is wrong. If the specification
/** = the number of primes in 2..102 */