How to truthfully stay DRY

"An article about Don’t Repeat Yourself? Please don't repeat common knowledge! Heard that, seen that, done that!" Really? Even though the pragmatic programmers who coined that term were very explicit about what DRY means it seems that the common understanding of DRY often falls short of fully comprehending this paramount concept.

DRY is not about factoring out parts of your code into methods or classes which would otherwise be repetitive. This is sometimes described as Once and Only Once. I take the liberty to say that DRY never bothered about that obviousness which was indeed heard, seen and done since the ages after punched cards by any programmer with a brain. Where does DRY apply then? Very simple: everywhere you deal with information. View your application outside your ruby, php, javascript, etc. and look at this piece of SQL:

CREATE TABLE users (
	id int identity(1,1),
	sPassword varchar(32),
	email varchar(64),
	bNewsletter type char(1),
	primary key (id)
)

I bet your application entertains good relations with a database in one way or another. 'Yes' you say, 'but what?' you ask puzzled, 'how could I repeat myself here?' Well you might want to consider a JavaScript validating corresponding user input and since we always have to validate on both ends (you didn't forget, did you?) You have to do the same validation on the server as well.

The same information hard coded in three places! What happens if we add a new field "URL" to our table or modify encoding from Latin1 to UTF-8? I tell you what happens: you will forget to update at least one of your information sources. If you are lucky you will catch any error with your tests. But I tell you: you won't be lucky and will have produced a juicy bug that is waiting to sprout legs and torch your application as soon as your customer gets his hands on the new version.

Now what can we do to protect us from such predictable disaster? DRY tells us what to do: no repetition of information, one source to rule them all. Any change to that master source has to propagate to all other sources.

In your case you might want to consider the SQL table creation script to be this source. The data needed for the two validation scripts get derived from it: bad idea. SQL is ignorant about data types you use such as password, email, etc. in addition you have a hard time modelling dependencies such as: email field required if newsletter checkbox is ticked. The client and server side code is not better suited for that trick.

I recommend using a configuration file in JSON format as your master source which is used by a shell script to generate all three files, sql, js and ruby/php/whatever and then recreates the table in the database. If you don't want to drop an existing table you could make your script as smart as to alter your table instead.

Concerning your validation you might be tempted to have the shell script incorporate the logic into your methods directly: again, bad idea, you would contaminate your dry and clean code with repetitive information. Instead refactor your validation scripts to generic methods that work with external data objects that include all information needed to validate your forms. Only those are generated.

Such a configuration script might look something like the JSON below:

oUserData = {
	"indexes" = [
		"email"
	],
	"encoding" = "UTF-8",
	"formId" = "registration",
	"fields" = {
		"sPassword" = {
			"sqlType" : "varchar",
			"formType" : "password",
			"length" : 20,
			"validates" : {
				"required" : true,
				"isPassword" : true
			}
		},
		"email" = {
			"sqlType" : "varchar",
			"formType" : "text",
			"length" : 20,
			"validates" : {
				"required" : true,
				"isEmail" : true
			}
		},
		"newsletter" = {
			"sqlType" : "char",
			"formType" : "checkbox",
			"length" : 1,
			"validates" : {
				"required" : false,
				"dependsOn" : [
						"email"
					]
			}
		}
	}
}

You now might argue that we still replicate information, indeed, all four files (even one more OMG!) hold - at least partly - the same information. However, generating those pieces of information is no breach of DRY at all since you do not treat them as "normal" code. The generated files are by no means maintained nor are they put under version control. You will never touch them, they are only created if your data or validation model needs to be changed or you build the application.

As you can see the principle DRY has much more to it as you might have thought initially. It not only helped us to avoid broken code because of changes "outside" the coders realm but also brought us to a situation where we refactored our code to be used in the next project!

We also see that we touch other areas such as configuration management or database administration. Most probably some smart guy keeps a jealous watch on those sacred grounds, help him understand why he also should stay dry!