Programming Terms: DRY (Don't Repeat Yourself)

TL;DR

DRY (“Don’t Repeat Yourself”) targets repeated information because duplication makes code harder to maintain and easier to update inconsistently.

Briefing Cornell Notes

Briefing

DRY—“Don’t Repeat Yourself”—is a software development principle that targets repeated information in code because repetition makes systems harder to maintain and easier to break when requirements change. In practice, DRY pushes developers to centralize shared logic (and shared data) so updates happen in one place instead of being manually replicated across many files or functions.

A simple example uses a Python project with three pages: a homepage, an about page, and a contact page. Each page prints the same header and footer HTML, and each also repeats similar structural elements. That duplication becomes a maintenance problem: if a developer needs to add a new link to the header, they would have to edit every copy of the header code across multiple page sections. DRY suggests extracting the repeated header and footer blocks into dedicated functions—such as a function that prints the header and another that prints the footer—then calling those functions from each page. The result is cleaner code and a single “source of truth” for shared layout.

The example goes further by noting that even repeated navigation menus can be centralized into a separate “nav menu” function. The payoff depends on how often the duplication occurs: pulling out something repeated only once or twice may not be worth the extra abstraction, but duplication that appears file after file typically benefits from DRY refactoring. After the refactor, the pages still render the same output—homepage content, header, footer—showing that maintainability improvements don’t have to change behavior.

A more practical scenario uses unit testing for a small calculator module (add, subtract, multiply, divide). The tests repeatedly set the same input values (for example, num1 and num2) in every test case. DRY recommends moving that repeated setup into a common setup step that runs before each test. In Python’s unit testing framework, a setup method handles this initialization automatically. With the repeated value assignments removed from each individual test, the test code becomes easier to read, and changing the test inputs requires editing only one location. The calculator tests still run successfully after the refactor, confirming that centralizing repeated setup improves maintainability without breaking correctness.

Overall, DRY matters because it reduces repetition of information—whether it’s HTML structure or test initialization—so future changes are faster, safer, and less error-prone.

Cornell Notes

DRY (“Don’t Repeat Yourself”) is a software principle aimed at reducing repeated information in code to make maintenance easier. A common failure mode is duplicating shared structure—like the same header and footer HTML—across multiple pages, which forces developers to update many places for a single change. Refactoring fixes this by extracting repeated parts into functions (e.g., print_header and print_footer, and optionally a nav menu function) so updates happen in one central location. The same idea applies to testing: repeated test inputs can be moved into a unit test setup method that runs before each test, keeping individual test cases focused on assertions. Centralizing repeated data and logic reduces clutter and lowers the risk of inconsistent updates.

Why does repeating code—like headers and footers across multiple pages—create real maintenance risk?

When the same header/footer HTML is copied into several page sections, a change request (such as adding a new link to the header) requires editing every duplicated block. That increases the chance of missing one copy, creating inconsistent UI or broken behavior. DRY reduces this risk by placing shared layout in one function so the update happens once and propagates everywhere.

How does extracting repeated HTML into functions make the code “DRY”?

The refactor moves the repeated header and footer blocks into dedicated functions (for example, a function that prints the header and another that prints the footer). Each page then calls these functions rather than embedding the same HTML repeatedly. This centralizes the shared information and makes the code easier to read because the page-specific content stands out.

When should developers avoid over-applying DRY?

DRY can lead to extra abstraction. In the example, centralizing the navigation menu provides less benefit because the menu is repeated only once or twice. The practical rule is that the biggest gains come when duplication appears repeatedly across many files or sections; small, infrequent duplication may not justify the added complexity.

How does DRY apply to unit tests in the calculator example?

Each unit test case sets the same input values (num1 and num2) before checking results for add, subtract, multiply, and divide. Instead of repeating those assignments in every test, Python’s unit testing framework provides a setup method that runs before each test. Moving the shared initialization into setup makes the tests cleaner and ensures input changes happen in one place.

What does the setup method change about the structure of test code?

It removes repeated value-setting lines from each individual test function. The tests become primarily about assertions—verifying that operations produce expected outputs—while the setup method handles consistent preconditions (like num1 and num2) automatically before each test runs.

Review Questions

Give two examples of repeated information in code and explain how DRY would address each one.
Describe how a centralized function changes the maintenance workflow when a shared UI element needs updating.
In unit testing, what repeated setup values might be good candidates for moving into a setup method, and why?

Key Points

1
DRY (“Don’t Repeat Yourself”) targets repeated information because duplication makes code harder to maintain and easier to update inconsistently.
2
Extract repeated shared UI elements (like headers and footers) into functions so changes happen in one central location.
3
Centralizing navigation menus can further reduce duplication, but the benefit depends on how frequently the menu is repeated.
4
Avoid over-abstraction: if duplication occurs only once or twice, the maintenance gain may not justify the added complexity.
5
In unit tests, repeated initialization values (like num1 and num2) should be moved into a setup method that runs before each test.
6
Using a framework-provided setup step keeps test cases focused on assertions rather than repeated preconditions.
7
After refactoring for DRY, behavior should remain the same—tests should still pass and page output should remain unchanged.

Highlights

DRY turns scattered, duplicated header/footer code into a single source of truth, so adding a new header link requires editing one place.

Centralizing navigation and other repeated layout elements reduces the risk of inconsistent updates across pages.

In unit testing, moving repeated input values into a setup method makes tests cleaner and makes changing test data a one-location edit.

DRY refactoring can improve readability and maintainability without changing the program’s output or test results.

Topics

DRY Principle
Code Refactoring
Python Functions
Unit Testing
Maintainability