CSC/ECE 517 Summer 2008/wiki2 5 31

From Expertiza_Wiki
Jump to navigation Jump to search

DRY Principle

The Don't Repeat Yourself (DRY) principle is basic to writing maintainable code. The purpose of this Wiki is to find Web sites that explain the importance of the principle by writing prose that summarizes their arguments. Examples will be provided of where the principle should be applied. A checklist will be created for programmers to consider in determining whether their code is in conformance.

What is the DRY Principle?

The DRY philosophy is stated as every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The DRY Principle means you should ensure that every bit of knowledge of your system, be it in the source code, its documentation or any other documentation, should have a single representation.

The Importance of the DRY Principle?

DRY, is also known as Single Point of Truth. The DRY coding philosophy requires that information not be duplicated. Duplication of data makes code less explicit and requires additional steps to fully implement any change in the code. With a single authority for a given piece of knowledge within a code structure, the programmer need only change the core authority to effect change throughout the structure. The results of changes to coding are predictable as all the logical connections to the altered data remain in agreement. Likewise, unrelated knowledge is left intact.

Ultimately, the goal of the DRY principal is to make code maintenance easier. At first glance, some projects may seem like maintenance will not be much of an issue. The project may be very small or the parameters seem defined well enough that, once completed, the project will not need further adjustment. In reality, it is rare that code is ever complete. In fact it has been shown that requirements change at a rate of two percent per month[1]. Even if one were to ignore the possibility of change requirements after code is complete, one must consider the following question: How often is a complete section of code written, never to be altered, on the first try? The truth is that maintenance begins immediately after anyone alters anything in the existing code. In other words, it is virtually impossible not to do maintenance. If data or code is repeated and maintenance needs to be done it will require the programmer to make changes and substitutions everywhere in the code where the repeated data or code exists. Programmers are people and people will make errors. Eventually a replacement will be missed somewhere in the code. Having a single point of truth or authority for a particular piece of data will require the programmer to correctly alter the code in only one location and he or she can be assured the changes will populate correctly throughout the rest of the related code.

Code written following the DRY principle, given its nature, will allow for easier changes and will allow many changes to be made with decreased likelihood of error. Errors introduced late in the development process are typically the most time-consuming and therefore the most expensive to fix. The advantages of having followed the DRY principal increases as the development process progresses. Late in the development process the code will be voluminous (relative to early in development) and more complex. Adherence to the DRY principle will allieviate a significant number of coding errors that would result from the implementation of change to repeated code or data.

Examples of the DRY Principle

Inadvertently, you may introduce duplication into your model without realizing that you are doing so. Suppose you have a class that represents a line as follows: 

 class line {
    public:
     Point start;
     Point end;
     double length;
 };

Although this may appear to be a reasonable class for defining a line but we have duplication. If for example we store the start and end points and then the length we will have a problem if one of the points changes. The length will be incorrect. It would be much better to have the length be calculated from the existing start and end points. 

 class line {
    public:
     Point start;
     Point end;
     double length() { return start.distanceTo(end); }
 };

Now we are not duplicating any information in our class and are following the principle of Don't Repeat Yourself.


Another example 

One of the most common ways to implement the DRY principal is with the use of code generators.  Although it is
technically not generating usable code, JavaDoc uses the existing Java code to generate documentation for its code. 
If the documentation was written independently of the code then changes to the code would very likely require changes 
in the documentation.  With JavaDoc, since the documentation is generated from the source code, the documentation 
will still be relevant after maintenance is performed on the code.  Using code generators like JavaDoc helps to 
allow a single authority on a piece of knowledge within in the code to be maintained.  The programmer changes the code 
and the change is properly documented as a result.

Programmer Checklist for the DRY Principle

 •If you have duplicated data in your code because it has to have different
representations in different places, can you write a function, tool or code
generator to make one representation from the other, or all from a common source?

 •If your documentation duplicates knowledge in your code, can you generate parts
of the documentation from parts of the code, or vice-versa, or both from a common
higher-level representation?

 •If your header files and interface declarations duplicate knowledge in your
implementation code, is there a way you can generate the header files and 
interface declarations from the code?

 •If you have metadata, tables, or constants they should be declared once an imported
elsewhere. 

 •If you have reused a section of code, a change will require finding all the sections
that involved reuse.  Missing some of the changes will often cause very subtle errors.

DRY Principle - Always Good?

Considering the increasing reuse, re-adaptation, and maintenance of code it appears as though it is rarely adventageous to ignore the DRY principle. The only instances where it may be beneficial to ignore the DRY principals is when the cost of following the principal is greater than effort of maintaining separate copies of data. An example would be something very small-scale that will not require any meaningful maintenance. As mentioned earlier, code often starts in this diminutive form and then morphs into something much greater, so, again the DRY principle should be ignored with caution.

Another example of where it might be beneficial to ignore the DRY principal is in a forum where "imposing standards aimed at strict adherence to DRY could stifle community involvement in contexts where it is highly valued, such as a Wiki."


Conclusion

As stated throughout the article, the benefits to following the DRY principle almost always outweighs the benefits of ignoring them. It is almost impossible to create and use any significant amount of code and not have to perform maintenance on that code. Maintenance and clarity are the main benefits derived from this principle as it helps to remove some of the human errors that can occur in updating code - especially code that is redundant. In many cases it may take a little longer to generate initial code using the DRY principle, but the time will likely be recouped as soon as any maintenance is required. It is enormously time consuming to find every occurrance of a piece of knowledge within a sizeable code structure if the DRY principle has not been followed. With the principle employed, the programmer needs only to find the one relevant section and make the necessary changes. All logical connections will automatically change predictably to accomodate and unrelated knowledge will be left intact.

External Links/References

[1]Hunt, Andy and Thomas, Dave Keep It DRY, SHY, and Tell the Other Guy, IEEE Software, vol. 21, no. 3, pp. 101-103, May/Jun 2004 PMID: 9917440; UI: 99117608.


Back to the assignment page

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Summer_2008/wiki2_5_31&oldid=13975"