Keeping Your Code Dry For Dummies

Writting code is not an easy task. There is a different paths to take that could lead you to the same result, however, the quality of what you write varies GREATLY depending on the approach that you decided to take.

There's a philosophy that most proficient software developers as one of the ways to measure code quality. That is DRYness.

Don't

Repeat

Yourself

This is pretty much identifying the logic that gets repeated throughout your codebase, placing it in a function or procedure, and then calling that function whenever you require that functionality.

This is much easier said than done. In reality, it is quite a challenge to identify which code repeats. However, there are two ways in which we can keep our code dry.

A- Thinking Abstract First

You could see a lot of this in Stanford's CS101 lectures found in iTunesU. It pretty much sums up to calling functions before you define it. Thinking about expected functionality BEFORE you define how that functionality works.

Example:

We have a robot instance that has 2 methods. .goForward() and .turnRight(). How could you make it do a 180 turn and then move 5 spaces?

Abstract way:

var robot = new Robot();
robot.turnAround();
robot.moveForward(5);

Here you have not defined .turnAround() or .moveForward(). But you understand that the robot needs to do this functionality. You will worry about defining and writing this functions after you have a clear path for your logic.

B- Auditing and Refactoring

The other way is just building functinality directly, testing that it works, auditing your code to see when are you repeating yourself and then refactoring into functions the part of your code that is being repeated.

Being DRY is not an option these days. However, you have to be wary, trying to overdo it could prove to be detrimental to your coding speed. Writing all your code upfront without separating logic into functions would make your code a nightmare to audit. On the other hand, thinking about every abstraction in your code upfront will keep you from shipping stuff faster. Ideally, your approach should contain a healthy combination of both Thinking Abstract First and Auditing and Refactoring.