A software acronym people really seem to enjoy is DRY - Don't Repeat Yourself. As usual, the best way to understand it is to learn basic computer programming, then think "DRY is a less-than-useful way to restate what I already know." It's a bit like telling drivers not to get into accidents. Not wrong, but also not helpful.
The original version sounds better: a piece of knowledge should only be in one place. Or the way I think of it: share instead of copy. That's true for the common-sense reason: copying is a waste of time and space if you could share, and the copies can become out-of-synch.
All you need to do is learn about using constants, functions, when to make a struct, and arrays. You have to learn those anyway. Then you might reflect that all of those result in shorter code, or on any other amusing factlets.
This code uses a margin of 0.15 in two places, and could be improved by using a constant. If the margin changes, we need to track down both and change them:
xPos = 0.15 + c*6; // measuring from left side useableWidth = width - 0.15*2; // count both margins
With constants (or as some people put it "never hard-code anything"):
const X_SIDE_GAP = 0.15; // the one place "knowledge" of the margin occurs xPos = X_SIDE_GAP + c*6; useableWidth = width - X_SIDE_GAP*2;
This avoids repeating the 015, but that's not how we teach it. We explain it as a positive -- we now have a single spot to change the margin size. We also have self-documenting code. All-in-all, "using constants" is it's own trick.
We first teach functions as ways to move code out of the way, and give it a nice name. Then we quickly show how it saves duplicating code. But functions are also about abstraction: once we agree to use the function resetShape() to reset the shape, we don't need to know how it works, and assume it's always updated correctly.
Functions are their own trick, with multiple useful attributes.
Simple structs are another not-repeating-ourselves use, but not really. The standard example is something like this:
// informal Dots with groups of variables:
double x1, y1, radius1, x2, y2, radius2; // variables for 2 dots
// as a class:
struct Dot { double x, y, radius };
Dot d1, d2;
The main thing we did is formalize an abstraction. We were imagining x1, y1, and radius1 made a Dot. Now they officially make a Dot. It also avoids duplicating variable declarations, which is nice, but only a part of it. Structs are best thought of as their own trick.
A common intro to arrays has us doing something to several variables with repetitive code, then again with a loop:
int a0, a1, a2, a3, a4; // a non-array array
if(a0>10) a0=10; // yikes
if(a1>10) a1=10;
...
// better using the magic of arrays:
int A[5];
for i index in A { if(A[i]>10) A[i]=10; } // "can't be more than 10" only written once
The array saved us from duplicating the compare line, but it's a lot more than that. You don't use an array to avoid duplicating code -- you use an array to have an array.
Once you've learned that stuff, DRY is merely a weird summary. It's like learning about traffic lights and turn signals, and summing up "remember this rule: don't get in an accident".
What bugs me the most is how non-DRY code is called WET. Computer Scientists should know better. Not dry merely means there is at least some water on you somewhere. You could be damp, or moist. Thinking not-dry is wet is a rookie mistake.
Comments. or email adminATtaxesforcatses.com