So what is DRY?
So the most fundamental coding principle (in my humble opinion) is DRY. This has been called lots of things, most popularly DRY or DIE (Duplication is Evil) but I like to sum it up as SHY. SHY explains why DRY is important and that reason is ‘Stop Hitting Yourself’.
Software code is often the result of a business requirement or scope, rather than an organic need. This means you will often need to achieve something on a scale beyond that of normal use and this scale is where DRY comes in.
A DRY Example
Imagine a scenario where you have to update 5 product records with a new category code. This code be achieved through something like
product[0].category = “New Category”;
product[1].category = “New Category”;
product[2].category = “New Category”;
product[3].category = “New Category”;
product[4].category = “New Category”;
Ultimately, this achieves the result, but is not very efficient and requires a lot of typing. Also, consider what happens if you don’t know how many categories are going to be on the list, or if you have to update 50 or 100 records. That’s a lot of code to write when the same could be achieved with a loop.
foreach (Product product in products) {
products.category = “New Category”;
}
This creates a simple loop in 3 lines of code, that achieves the same result as the first example achieves in 5. Of course, there is a tiny argument against this, which is that if you have two records and can update them in 2 lines then the overhead of 3 is undesirable. Realistically though, anything you need to do on scale, you can apply DRY to limit the amount of code you write to achieve this.
How can you apply DRY to your code?
Now, this can apply to your code in lots of different ways.
- Declare constant variables. Think connection strings, domains, companies names or admin email addresses. All of these things will often be used regularly throughout a web application and using a constant variable allows you to access them easily as well as easily update them if needed.
- Create loops for predefined logic. Think of the example above and hopefully this one is obvious.
- Create procedural methods for regular logic. Think of a contact form that requires you to check phone numbers and email addresses. You can easily create a method to apply a test and use that to switch the logic for phones or emails. You can then call this single method throughout your application instead of writing that test each time you need it.
- Review your code. This is the most important one. In the early days, you won’t know what’s a good thing to separate out into its own method or not. Reviewing your code (often called a code review or a code retrospective if at the end of the project) is a great way of literally teaching yourself because you can see where you could have done better.
Summary
Repeating code over and over is a tedious job and is comparable to hitting yourself in the face. It’s obviously better to STOP HITTING YOURSELF (SHY) and DON’T REPEAT YOURSELF (DRY). When in doubt just think, am I using this more than once? And if so, can this be declared as a constant, looped through or logic removed and call through a method?
Masters Development 