DRY vs WET Code

John Long
JL Codes
Published in
3 min readNov 12, 2017

Dry, Wet, Hot, Cold. These are just words, right? I’m here to tell you they may be more.

Art by Noah Bradley

Most, if not all, programmers will have heard of the terms DRY and WET as they pertain to code. But, let’s first declare what these acronyms stand for so none are ill-informed.

DRY — Don’t Repeat Yourself

WET — Write Everything Twice

Take a second to ponder… which acronym sounds like it might be the better coding practice? If your inkling nudged you towards DRY, you would be correct. Well, 90% of the time.

As a programmer striving to keep your code DRY, thus, not repeating your code, is generally the best practice. But there are times where having some moisture added to your code may make your life a little easier.

Let’s first take a look at an example of each.

Here is what some WET code looks like: (using Ruby)

class John
def build(n)
n + 1
end
def destroy(n)
n - 1
end
end
class Peter
def build(n)
n + 1
end
end

Did you spot the Write Everything Twice spots?

In this case, both classes, John & Peter, have the ability to use the build method. However, if a future change was to be made to the build method, it would need to be done twice, at each spot the build method is used.

On the other hand, if the code was DRY, we’d only have to make that change once. In this case, using a module might help keep our code DRY:

module Builder
def build(n)
n + 1
end
end
class John
include Builder
def destroy(n)
n - 1
end
end
class Peter
include Builder
end

Using a module allows both classes the ability to build. And, of course, John still keeps his destroy method.

Keeping your codebase DRY is most helpful in places where you foresee changes happening fairly frequently. Having DRY code means you only need to make those changes in one, or a few areas, rather than all the places where that code may be used.

Perhaps most importantly, having DRY code reduces your chance for error. Imagine a change needs to be made to identical code in five different spots, but you forget to change the code in one of those spots… See the problem? Either your program will crash, or perhaps even worse, use an outdated procedure while appearing normal.

That being said, WET code does have its merits. If you anticipate the identical code forking in different directions later on, having WET code may make that future change easier.

Additionally, overly DRY code can create headache to the next programmer who uses your code, which may include yourself. This can stem from making a tedious amount of logical jumps in order to figure out the factors at play in a particular line of code.

That being said, as a general rule of thumb, keep your code DRY folks. The you of tomorrow will appreciate it.

--

--