CSC/ECE 517 Summer 2008/wiki2 5 31: Difference between revisions
Line 37: | Line 37: | ||
•If your documentation duplicates knowledge in your code, can you generate parts | •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 | of the documentation from parts of the code, or vice-versa, or both from a common | ||
higher-level representation? | higher-level representation?<BR> | ||
•If your header files and interface declarations duplicate knowledge in your | •If your header files and interface declarations duplicate knowledge in your | ||
implementation code, is there a way you can generate the header files and | implementation code, is there a way you can generate the header files and | ||
interface declarations from the code? | interface declarations from the code?<BR> | ||
•If you have metadata, tables, or constants they should be declared once an imported | •If you have metadata, tables, or constants they should be declared once an imported | ||
elsewhere. | elsewhere. <BR> | ||
•If you have reused a section of code, a change will require finding all the sections | •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. | that involved reuse. Missing some of the changes will often cause very subtle errors. |
Revision as of 13:58, 25 June 2008
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. This process is aimed at simplifying the maintenance of code. The philosophy emphasizes that information should not be duplicated, because duplication increases the difficulty of change, may decrease clarity, and leads to opportunities for inconsistency. When the DRY principle is applied successfully, a modification of any single element of a system does not change other logically-unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync.
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.
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.
External Links
- http://www.pragprog.com/titles/tpp/the-pragmatic-programmer
- http://www.catb.org/esr/writings/taoup/html/ch04s02.html
- http://www.artima.com/intv/dry3.html
- http://blogs.msdn.com/steverowe/archive/2008/05/15/design-principle-don-t-repeat-yourself.aspx
- http://en.wikipedia.org/wiki/Don't_repeat_yourself
- http://en.wikipedia.org/wiki/DRY_code