Existing Code - Principles
1. We adhere to the style of the original.
When modifying existing software, our changes follow the style of the original code
unless changes to rewrite a new coding style is explicitly requested within the scope of the project.
There are several reasons why we feel that it is usually not economically beneficial to rewrite old software just to make it match the new style:
- The choice of any particular style can be rather subjective, costing more in time for discussions than just the programming and debugging effort.
- Use of different styles within a single source file produces code that is more difficult to read and comprehend.
- Changes for any reason carry a risk of introducing defects.
2. We adhere to the Principle of Least Astonishment.
We avoid doing things that may surprise people (other programmers and users of our software).
We aim to make the interaction and behaviors exhibited by our software predictable and consistent.
3. We aim to do it right the first time, right from the start.
By experience, we know that, more often than not, supposedly prototype or experimental code
make their way into a system people depend on.
It's difficult and time consuming to decipher code,
We never know whether we will have an opportunity to "finish up" a piece of code.
So, we consistently:
- create a new programming file by completing the programming identifying comments before
editing code.
- make an entry in the change log to describe and justfiy the changes we intend to make before we make those changes.
4. We justify deviations to Standards
If we do not feel that a particular standard (whether defined in a document or implicit in existing code),
we explain why in the coding and clearly identify where deviations are necessary.
This is especially important when implementing any unusual patterns of use or behavior.
|
|
The programming standards we follow are based on these books and websites:
The Elements of Java Style
(Cambridge University Press, 2000)
by Al Vermeulen
|
|
|