What is DRY code and is it good for you?

“Don’t Repeat Yourself” Famously known as DRY code is a principle or pragmatic philosophy for Software Architects and Engineers which was introduced in the late 90s by Andy Hunt and Dave Thomas in a book called “The Pragmatic Programmer”.

This is something that many beginners get introduced to and don’t have much context about, well for starters it just means writing blocks of codes in such a manner that repetitiveness is reduced to almost none which is done through generalizing pieces of codes or modules as functions so that in a system where lots of changes are being made or huge codebases are handled we can simply introduce functionalities or make changes into existing ones in a single place.

Understanding the meaning of DRY

One of the biggest misconceptions related to DRY code is that the principle tells you to minimize the lines of code, well that’s totally what the DRY philosophy trying to teach you. DRY code is not about reducing the number of lines written in your programs, it is rather about generalizing your problem’s logical solutions into a single point of reference from where you could access the logic for manipulation for adding more to it. It helps you write a mannered and structured form of logic systems which leads to the reduction of code duplication which is not always necessarily the same as just “Reducing the lines of Code”

Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

The Pragmatic Programmer (1999)

Here if we observe the quote mentioned above from the book, it nowhere mentions the reduction of lines of codes rather it talks about the DRY principle in such a manner that it relates to a coder as well as an architect. “Every Piece of Knowledge”, well to us it can mean something as simple as just Business logic or Core Functional Requirements of our Software, so it is referring that Whatever logic we construct for the system must have such representation that it only is defined at a single place and then it can be reused multiple times anywhere else whether if it’s in the internal environment or external environments in forms of libraries, frameworks or APIs.

Example of Using DRY

The example shown below is a basic one and should get you the hang of using DRY code

Duplication in Code

john_marks = { "Maths": 72, "Science": 61 }
jane_marks = { "Maths": 82, "Science": 78 }

def get_john_report(marks):
    print(marks["Maths"])
    print(marks["Science"])
    return 

def get_jane_report(marks):
    print(marks["Maths"])
    print(marks["Science"])
    return

get_john_report(john_marks)
get_jane_report(jane_marks)
Code language: Python (python)

Cleaning Up the Code

john_marks = { "Maths": 72, "Science": 61 }
jane_marks = { "Maths": 82, "Science": 78 }

def get_student_marks(student):
    print(student["Maths"])
    print(student["Science"])
    return

get_student_marks(john_marks)
get_student_marks(jane_marks)
Code language: Python (python)

So the example shown above is far away from what we implement in real life however I just wanted to showcase how DRY code is just about creating logic blocks that can be reused multiple times

Pros of Using DRY Principle

• One of the major advantages is that it enables you to have a single point of reference to make modifications for each logic block that you have created
• It increases the reusability of code, which in turn increases the development productivity and makes the environment a bit neater to work
• Since you have maintained the logic blocks into generalized or abstracted forms you can run multiple tests on them and have better testing of the code
• It can improve the maintainability of the codebase since modifications are easy and one place changes
• The DRY principle can be used in almost all phases of engineering a software or web product and is not just bounded to being a coding principle

Problems with Overusing the Principle

• Since these are just principles for you and your work, it does not mean they are unbreakable rules so overusing them sometimes can turn your code into over-abstracted and non-readable code which is harder to debug and maintain among developers
• Sometimes two or more pieces of logic blocks look similar and trick you into thinking they should be generalized into a single piece of a block but that’s not necessary, you shouldn’t overthink about the future and write code in terms of what you need now since those similar looking blocks might be just as great on their own but when you try to abstract them you later realized they are over abstracted and didn’t need any refactoring at all, to begin with

Conclusion

In short, DRY code is about reducing the number of times the same logic is written in code but not in a way that harms the project’s codebase or readability, it does not indicate reducing the lines of code and clean code is not always just about lines of code and how you name variables, etc.

You shouldn’t overuse this principle much and there isn’t any need to apply the DRY principle everywhere in your system if you aren’t sure about it, work thoroughly your system planning and see if you need to use it then make changes accordingly, DRY can be good and bad both for you, it just depends on how you interpret and use this principle!