The DRY (Don't Repeat Yourself) Principle

Published on Tue Jul 21 2020

DRY stands for Don't Repeat Yourself, which basically means to avoid writing duplicate code. The textbook definition of it is that every piece of knowledge or logic should have a single unambigous, authoritative representation within a system.

If you find a block of code that is repeated multiple places, consider using abstraction or moving the code to a common method. Similarly, if you use a hard-coded value more than once, try making it a constant or a configuration.

The primary benefit of following DRY principle is the ease of code maintenance. Changing functionalities in the future will be much easier because you don't have to remember all the places where the code needs to be changed. That also translates to reduced bugs, readability and better evolution of the code.

Beyond Code

DRY Principle can be extended beyond code. You can use the principles when designing a database, writing documentation, build scripts, documentation, test cases, and even humman communication within a project. And if you think you might find applications in your personal lives as well. For instance, a capsule wardrobe is an example, or you can use it in your note-taking apps by linking to existing notes (some people call it creating a second-brain)!

How to apply DRY principle:

  1. Functions: This is the most common application and easiest to do. If you find yourself writing the same block of code more than once, extract it to a function.
  2. Classes and Objects: Can the logic and datastructures be encapsulated into a class?
  3. Design Patterns: Many design patterns are essentially ways to apply DRY principle.
  4. Libraries and Frameworks: Leverage existing libraries and frameworks. Just make sure the library is well maintained, tested and trustworthy.
  5. Configuration Files: For environment specific variables and similar configurations, use configuration files instead of hardcoding it.
  6. Database Normalization: When designing a relational database, normalize the data, whenever appropriate.

When not to use?

An important point to remember here is to not abuse the principle. Do not force abstractions prematurely. Do not abstract things that are superficially similar but have fundamentally underlying concerns. For example, A squaare is a rectange in the realworld, but not for a programmer. Using a rectangle as a super-class of Square would lead to issues because rectangle's behaviour (users can set length and width separately) is different from square's behaviour (only one side). We are not concerned about code duplication, but functionality duplication, and there is a difference. It means you should never use a standard code for two functionalities that have similar code but are logically unrelated. Doing it will tightly couple two different functionalities together and changing one of them in the future will become harder.

Conclusion

The DRY principle is more than just a coding guideline. It's a mindset that promotes efficient, roboust, and scalable software development. Our aim is to eliminate redundancy and create systems that are easier to maintain and make our teammate's lives a little better, and our future self's life too.