Subtle Redundancies

On the XpMailingList, RobertSartin? wrote:

It's not death, but it is a significant code smell, to have System.in sprinkled all about the code.

There is an amazing volume of such latent, hard-to-notice OAOO violations.

Some other examples, of varying danger, include:

Common data in the code

(See the sad situation on SystemVsApplicationLevelDecisions)

References to class names in plural, weird places

A class header, implementation file, corresponding test class header and implementation files, references to the above in CVS, references to the headers in scattered #include directives, compiled object files, the repeated references to the names in the clients.

Using type names in object names (such are another weird place to suddenly realize you've been repeating yourself.

Of course, non-executable documentation only makes this situation worse.

Types themselves

(See TypesAreRedundant)

Syntactic redundancies

Having both braces ("{", "}") and indenting is a fine example -- both express the same information. Open up a source file, and try to look at the code anew -- you'll see many more examples.

Error handling

As an example, Imagine an application that gets XML as input.

Initially, you DoTheSimplestThingThatCouldPossiblyWork and skip having a DTD and type validation. As time goes on, you are bitten by various fields being invalid, and one by one you add validation and error handling. In the end, you have dozens of places that check the input then throw exceptions, when you could've just handled the whole thing by writing the DTD and trusting the input after it gets past it.

Note: I'm not claiming that writing the DTD up-front would've been better. I'm just saying that the concept of "check the input, raise an exception" was slowly duplicated, like a frog being slowly boiled.

Text editing: repeated tap-tap-tap-tap-tap's to move the cursor around or to delete.

I won't go into my "vi is the OnceAndOnlyOnce-aware editor" speech, since I'm actually beginning to believe that much of the text editing we do could be obseleted by better environments. (Blasted Smalltalk programmers with their incessant propaganda!!!)

The name "OnceAndOnlyOnce" itself

Someone pointed out that even the "OnceAnd" in "OnceAndOnlyOnce" is a violation of OAOO. I'm guessing that the name is ironic on purpose, but the fact that I did not immediately pick up on the joke is an indication of how thoroughly calloused my mind is against redundancy.

I would not be surprised if, given sufficient brainstorming and assumptions-testing ability, one could find millions of OAOO violations in any given program that are normally ignored, even by people who are familiar with the principle.

Once you notice these, it's often easy to see how they have added unwanted inertia and pain (if the ill effects of any of the above examples aren't clear, just let me know and I can elaborate).

[ Note to refactorers: Sorry this was done in the first-person tone -- don't let it make you hesitant to change things around ]