CSC/ECE 517 Summer 2008/wiki2 5 31: Difference between revisions
Line 32: | Line 32: | ||
= Programmer Checklist for the DRY Principle = | = Programmer Checklist for the DRY Principle = | ||
•If you have duplicated data in your code because it has to have two different representations in two different places, can you write a function, tool or code generator to make one representation from the other, or both from a common source? | •If you have duplicated data in your code because it has to have two different | ||
•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? | representations in two different places, can you write a function, tool or code | ||
•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? | generator to make one representation from the other, or both 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? | |||
= External Links = | = External Links = |
Revision as of 13:40, 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 two different representations in two different places, can you write a function, tool or code generator to make one representation from the other, or both 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?
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