dry-principle

# DRY Principle (Don't Repeat Yourself) ## Overview DRY (Don't Repeat Yourself), articulated in The Pragmatic Programmer by Hunt and Thomas, states: "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." Duplication creates maintenance burden—fixing bugs or changing logic requires updating multiple locations, inevitably leading to inconsistencies. ## When to Use - Noticing copy-pasted code blocks across files - Same business logic implemented in multiple places - Repetitive configuration or data structures - Multiple sources of truth causing sync issues - Bug fixes requiring changes in 5+ locations - Code reviews revealing duplication ## The Process ### Step 1: Identify Duplication Types **Code duplication**: Identical or similar logic repeated. **Knowledge duplication**: Same business rule expressed differently in multiple places. **Data duplication**: Multiple sources of truth for same information. **Example**: Validation logic for email format appears in signup form, profile update form, admin panel, and API endpoint. ### Step 2: Extract to Single Source of Truth Create function, class, module, or configuration representing the duplicated knowledge once. All uses reference this single source. **Example**: Extract `validateEmail(email)` function. All forms/APIs call this function instead of implementing validation inline. ### Step 3: Replace All Instances Find and replace duplicated code with calls to the new single source. Use search tools to find all occurrences. **Example**: Replace 12 instances of email regex validation with `validateEmail()` calls. ### Step 4: Test Thoroughly Duplicated code often has subtle differences (intentional or bugs). Verify that single source handles all edge cases from all original contexts. **Example**: Discover signup form allows `+` in emails but profile update doesn't. Fix `validateEmail()` to handle both correctly. ### Step 5: Prevent Future Duplication Add linting rules, code review checklists, or architectural patterns that discourage duplication. **Example:** Add ESLint rule detecting duplicate code blocks. Enforce code review question: "Could this be extracted?" ## Example Application **Situation**: SaaS app with authentication checks duplicated across 47 API endpoints. Bug discovered: JWT expiration not checked consistently. **DRY Refactoring**: - **Before**: Each endpoint has 10-15 lines checking JWT validity, user permissions, rate limits. Some check expiration, some don't. Bug fix requires updating 47 files. - **After**: Extract `authenticateRequest(request)` middleware. All endpoints use middleware. Bug fix requires changing 1 function. - **Deployment**: Roll out middleware incrementally, one endpoint at a time. Test each. - **Prevention**: Add architectural rule: "All new endpoints must use authentication middleware, no inline checks allowed." **Outcome**: Future auth changes take minutes instead of days. Security bugs fixed once, applied everywhere. Eliminated 500+ lines of duplicated code. ## When to Allow Repetition DRY is not absolute. Acceptable repetition: - **Coincidental similarity**: Code looks similar but represents different concepts. Abstracting would couple unrelated logic. - **Premature abstraction**: Don't DRY until pattern repeats 3+ times. "Rule of Three": Duplicate twice, abstract on third occurrence. - **Optimization**: Sometimes duplicated optimized code performs better than abstracted code. - **Testing**: Test code duplication is acceptable to keep tests independent and readable. **Example**: `formatDateForDisplay(date)` and `formatDateForAPI(date)` look similar but serve different purposes (UI vs. serialization). Don't force them into one function with flags—that couples UI and API concerns. ## Anti-Patterns - ❌ Premature abstraction (DRY-ing code that repeats twice but won't repeat again) - ❌ Wrong abstraction (forcing unrelated concepts into shared function because code looks similar) - ❌ Over-DRY: Extracting every 3-line block into separate function (decreases readability) - ❌ Ignoring WET (Write Everything Twice) guideline—abstract on third repetition, not first - ❌ DRY-ing across bounded contexts (microservices sharing code reduces independence) - ❌ Treating DRY as dogma vs. guideline (sometimes duplication is correct choice) ## Related - single-responsibility-principle - abstraction - refactoring - yagni - code-smells