| < Day Day Up > |
|
Docuphobia and i are closely related due to their impact on the understandability of the code. Once the i illness is conquered, Docuphobia is easier to remedy because less extra documentation is necessary. However, good naming does not fully replace the need for comments and other forms of documentation. This is particularly true of interfaces where the programmer should be discouraged from looking at the implementation. Good naming can still be applied to the interface names, but extra documentation should be made available to lessen the temptation to look at the implementation. Thus, preventing these illnesses is normally a joint effort.
Another close relation between Docuphobia and i is one of the common reasons they both occur. This is where Premature Optimization comes into play; only this time it is theoretical optimization of development time saved by short names and no documentation. Experience, unfortunately, tells a different story. Without the proper readability to the code, more time is lost fixing bugs that should have never happened and parsing code that should not have to be looked at.
The failure of short names to provide savings in development time is a result of Myopia. As is all too common, shortcuts taken early can lead to a much longer road later. Spend the extra time up front to provide good variable names and you will make it back when you do not have to do extra work at the end of the project.
| < Day Day Up > |
|