Sometimes, developers encounter a code that was developed before they started working on it. They often work on ongoing projects and have to adapt to what was previously done.A very important aspect of development is to also think about the side effects and how would a developed code behave in the future. This is the reason why it is important to keep your code clean. Imagine coming as a new developer into a new large-scale project where many developers have changed over the years. This often means a violation of clean code principles with different coding styles and bad code organization within a project. The code over time becomes unreadable and difficult to maintain
What is the DRY principle?
DRY is a principle introduced in 1999 by Dave Thomas and Andy Hunt in their book “Pragmatic programmer”. DRY (“Don’t Repeat Yourself”) principle follows the idea of every logic duplication being eliminated by abstraction. This means that during the development process we should avoid writing repetitive duplicated code as much as possible. This principle can easily be implemented in any programming language.
How to achieve DRY code?
There are several ways you can write DRY code. But the implementations might be diverse depending on the developer’s use cases.
Write reusable functions for repeated tasks
Reusable functions are the best way to achieve this. Functions have inputs and outputs which allows us to rewrite multiple functions into a single one with extracted common parts.
Avoid errors with code execution with conditional statements
For example, this strategy can help us check if the variable exists before code execution. This is especially helpful when dealing with frontend state management.
Iterate over duplicated tasks
If there is a set of operations planned in a specific order, we can create a loop to iterate over those operations.
Why should you go DRY first?
There are several benefits to using this coding principle:
One of the most important benefits is readability. The code itself will not become more readable than it was, but you will have a lot less code coming from a single source.
This principle enforces reusability as we are merging multiple repeating code instances into one single instance. These individual instances can easily be reused all over the project
Less code means better performance and faster execution.
More code is more expensive
More code requires more effort which means more developers maintaining the code and fixing the bugs, so in long term, it would be cheaper for the company to focus on improving the code quality.
The same thing applies here. More code requires more tests. This doesn’t necessarily apply to the manual, but to the unit and integration testing. More code means more functions and various outcomes to test.
The biggest benefit of all is maintainability. Using DRY code becomes more robust making it harder to break. If we have repeated functionalities all over the project, it can become difficult to fix issues in this repeated code and you can often miss fixing these issues in other occurrences. If you use DRY you can easily pass different parameters into a shared function instead of copy-pasting the code.
Do not overdry your code!
If the code is “overdried” you get back to the point where you started, and the code becomes unreadable and difficult to understand. You need to know the limit and not overuse this principle.
Some code doesn’t need to be dried out!
It is very important to think through and know which code needs to be merged into a single instance. Sometimes code can look very similar, but it isn’t identical with minor differences, and on that occasion, we can leave the code as it is, so we don’t break something.
The DRY principle is great to use when developing a code when you want to keep in mind that you’ll have to revisit it in your projects. But, as with any other principle, the world isn’t always textbook perfect, so you have to be careful with its application in your work. It’s not always just about developing the code, but working towards achieving project objectives. Certain codes don’t need to be dried out if they are properly executing their task. So, tread carefully, and apply the principle when it’s aligned with what you want to achieve in the long run.