CSC/ECE 517 Summer 2008/wiki2 5 31: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
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
   •If you have duplicated data in your code because it has to have different
  representations in two different places, can you write a function, tool or code
  representations in different places, can you write a function, tool or code
  generator to make one representation from the other, or both from a common source?
  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
   •If your documentation duplicates knowledge in your code, can you generate parts

Revision as of 13:44, 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?

External Links

Back to the assignment page