Programmer Musings

The One, Right Place

Many years ago, I spent a lot of time training entry-level programmers. One of the problems that the more junior programmers had was duplicating code and information in the code. Some of our senior programmers at the time began talking about the concept of the one, right place. Later, I read the book The Programmatic Programmer and saw their concept of Don't Repeat Yourself (DRY). For a while, I switched to their definition. I've finally come to the conclusion that the one, right place and DRY are two similar, but not quite identical ideas.

The one, right place refers to the one place in a piece of code where a piece of information belongs. When this information is stored in many places, the code is harder to understand and maintain. The key point here is that there is a right place for the information. There may be other places where the information can be stored, but those places may not increase the understandability or maintainability of the code.

The DRY principle covers the concept that a piece of information should only be stored in one place. But no mention is made of whether any place is better than another. In particular, Hunt and Thomas state that

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system

Although you could gather that there is assume that there is a right place for this representation, that requirement is not explicitly stated. As such, someone could claim to be following the DRY principle when storing a piece of knowledge in a one, wrong place. This person might resist changing the authoritative reference because of the DRY principle.

One way to tell if you have the one, right place or a wrong place is if the information ends up being duplicated during maintenance. I've seen this where the authoritative copy of the information cannot be referenced without generating references to a large amount of unrelated information. In order to decrease the unnecessary overhead, a new copy is made. At that point both DRY and the one, right place have been violated.

The one, right place extends DRY to include some design relating to the location of that information. We should not need to include dozens of headers (in a C++ program) in order to get the size of a single data structure. We also should not need to include references to a GUI subsystem to access a thread function. When these kinds of knowledge are coupled together unnecessarily, we may be following the letter of DRY, but we are violating the spirit of the principle.

The one, right place is the spirit of the DRY principle.

Coding Standards

At different times in the past I've either agreed with or fought the application of coding standards. Recently, I've been looking at the subject again. In a wonderful case of timing I stumbled across an ad in CUJ (10/2004) for CodingStandard.Com. They have a coding standard for C++ that seems to cover much of what I was looking for.

Later in the same issue, the Sutter's Mill column had some more advice from the upcoming book C++ Coding Standards by Herb Sutter and Andrei Alexandrescu. In this column, they suggest not standardizing personal preference issues (indenting, brace placement, etc.).

This lead me to a useful concept that I need to explore further. What I've normally called a Coding Standard is actually two documents.

Coding Standard

This document covers the rules that increase quality and maintainability of the code. This includes subjects like when to throw exceptions and the usage of RAII. Most of the items that we call Best Practices fit here.

Style Guide

This document establishes style preferences to reduce incidental differences in the code. This includes brace placement, indenting, CamelCase vs. underscores, etc.

The important point is that most of the religious debates I've seen fall into the second document. Additionally, most of the stuff in the second document is a matter of preference, there is very little evidence that one style is significantly better that another. On the other hand, the items in the first document are usually demonstrably better than their alternatives.

By separating the two documents, we might be able to get two major benefits:

1. Don't avoid the best practices because you don't like the style of the second.
2. Allow the styles to change as needed without invalidating the standards.

This division also better reflects the purpose of the two sets of rules.

"Good Enough" Revisited

In The Forgotten Engineering Principle, I went on at some length about the concept of "Good Enough". I originally began thinking about this idea over a decade ago in the context of Stylus-Based Computers (what are now called Tablet PCs). I hadn't thought about the concept for quite a long time.

However, in doing a little research for another issue I found that I had been reminded of this concept just a few years ago. Unfortunately, I had forgotten that I had been reminded. Andrew Hunt and David Thomas devote a small portion of The Pragmatic Programmer to the concept of Good-Enough Software. Even if I didn't remember it at the time, I'm appreciate that they moved the concept back into memory far enough to keep me thinking about it.

So, in the Credit Where Credit Is Due department, Hunt and Thomas reminded me of this concept so they should get credit for some of anything good you might get out of my essay. I, of course, claim credit for anything you disagree with.