Don't repeat yourself

Last updated

"Don't repeat yourself" (DRY), also known as "duplication is evil", is a principle of software development aimed at reducing repetition of information which is likely to change, replacing it with abstractions that are less likely to change, or using data normalization which avoids redundancy in the first place.

Contents

The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system". The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer . [1] They apply it quite broadly to include database schemas, test plans, the build system, even documentation. [2] When the DRY principle is applied successfully, a modification of any single element of a system does not require a change in other logically unrelated elements. Additionally, elements that are logically related all change predictably and uniformly, and are thus kept in sync. Besides using methods and subroutines in their code, Thomas and Hunt rely on code generators, automatic build systems, and scripting languages to observe the DRY principle across layers.

Single choice principle

A particular case of DRY is the single choice principle. It was defined by Bertrand Meyer as: "Whenever a software system must support a set of alternatives, one and only one module in the system should know their exhaustive list." [3] It was applied when designing Eiffel.

Alternatives

WET

The opposing view to DRY is called WET, a backronym commonly taken to stand for write everything twice [4] (alternatively write every time, we enjoy typing or waste everyone's time). WET solutions are common in multi-tiered architectures where a developer may be tasked with, for example, adding a comment field on a form in a web application. The text string "comment" might be repeated in the label, the HTML tag, in a read function name, a private variable, database DDL, queries, and so on. A DRY approach eliminates that redundancy by using frameworks that reduce or eliminate all those editing tasks except the most important ones, leaving the extensibility of adding new knowledge variables in one place. [5] This conceptualization of "WET" as an alternative to "DRY" programming has been around since at least 2002 in the Java world, though it is not known who coined the term. [6]

AHA

Another approach to abstractions is the AHA principle. AHA stands for avoid hasty abstractions, described by Kent C. Dodds as optimizing for change first, and avoiding premature optimization. [7] and was influenced by Sandi Metz's "prefer duplication over the wrong abstraction". [8]

AHA is rooted in the understanding that the deeper the investment engineers have made into abstracting a piece of software, the more they perceive that the cost of that investment can never be recovered (sunk cost fallacy). Thus, engineers tend to continue to iterate on the same abstraction each time the requirement changes. AHA programming assumes that both WET and DRY solutions inevitably create software that is rigid and difficult to maintain. Instead of starting with an abstraction, or abstracting at a specific number of duplications, software can be more flexible and robust if abstraction is done when it is needed, or, when the duplication itself has become the barrier and it is known how the abstraction needs to function.

AHA programming was originally named "moist code" by Dodds, later again by Daniel Bartholomae, [9] and originally referred to as DAMP (Don't Abstract Methods Prematurely) by Matt Ryer. [10] There was a different programming principle already named DAMP (Descriptive And Meaningful Phrases) and described by Jay Fields, [11] and the community pushed back against the usage of MOIST, due to the cultural aversion to the word moist. [12] Dodds called for alternatives on Twitter, and suggested DATE as an alternative before settling on Cher Scarlett's suggestion of AHA. [7] [13] [14]

See also

Related Research Articles

<span class="mw-page-title-main">Transclusion</span> Including one data set inside another automatically

In computer science, transclusion is the inclusion of part or all of an electronic document into one or more other documents by reference via hypertext. Transclusion is usually performed when the referencing document is displayed, and is normally automatic and transparent to the end user. The result of transclusion is a single integrated document made of parts assembled dynamically from separate sources, possibly stored on different computers in disparate places.

A naming convention as a form of computer humour especially among playful programmers, yet another is often abbreviated ya, Ya, or YA in the prefix of an acronym or backronym.

In software engineering and computer science, abstraction is the process of generalizing concrete details, such as attributes, away from the study of objects and systems to focus attention on details of greater importance. Abstraction is a fundamental concept in computer science and software engineering, especially within the object-oriented programming paradigm. Examples of this include:

Copy-and-paste programming, sometimes referred to as just pasting, is the production of highly repetitive computer programming code, as produced by copy and paste operations. It is primarily a pejorative term; those who use the term are often implying a lack of programming competence and ability to create abstractions. It may also be the result of technology limitations as subroutines or libraries would normally be used instead. However, there are occasions when copy-and-paste programming is considered acceptable or necessary, such as for boilerplate, loop unrolling, languages with limited metaprogramming facilities, or certain programming idioms, and it is supported by some source code editors in the form of snippets.

In computer science, separation of concerns is a design principle for separating a computer program into distinct sections. Each section addresses a separate concern, a set of information that affects the code of a computer program. A concern can be as general as "the details of the hardware for an application", or as specific as "the name of which class to instantiate". A program that embodies SoC well is called a modular program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Encapsulation is a means of information hiding. Layered designs in information systems are another embodiment of separation of concerns.

Test-driven development (TDD) is a way of writing code that involves writing an automated unit-level test case that fails, then writing just enough code to make the test pass, then refactoring both the test code and the production code, then repeating with another new test case.

A programming tool or software development tool is a computer program that software developers use to create, debug, maintain, or otherwise support other programs and applications. The term usually refers to relatively simple programs, that can be combined to accomplish a task, much as one might use multiple hands to fix a physical object. The most basic tools are a source code editor and a compiler or interpreter, which are used ubiquitously and continuously. Other tools are used more or less depending on the language, development methodology, and individual engineer, often used for a discrete task, like a debugger or profiler. Tools may be discrete programs, executed separately – often from the command line – or may be parts of a single large program, called an integrated development environment (IDE). In many cases, particularly for simpler use, simple ad hoc techniques are used instead of a tool, such as print debugging instead of using a debugger, manual timing instead of a profiler, or tracking bugs in a text file or spreadsheet instead of a bug tracking system.

In computer programming, a software framework is an abstraction in which software, providing generic functionality, can be selectively changed by additional user-written code, thus providing application-specific software. It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products and solutions.

<i>The Pragmatic Programmer</i> 1999 non-fiction book by Andrew Hunt and David Thomas

The Pragmatic Programmer: From Journeyman to Master is a book about computer programming and software engineering, written by Andrew Hunt and David Thomas and published in October 1999. It is used as a textbook in related university courses. It was the first in a series of books under the label The Pragmatic Bookshelf. A second edition, The Pragmatic Programmer: Your Journey to Mastery was released in 2019 for the book's 20th anniversary, with major revisions and new material which reflects new technology and other changes in the software engineering industry over the last twenty years.

"You aren't gonna need it" (YAGNI) is a principle which arose from extreme programming (XP) that states a programmer should not add functionality until deemed necessary. Other forms of the phrase include "You aren't going to need it" (YAGTNI) and "You ain't gonna need it".

In software development, code reuse, also called software reuse, is the use of existing software, or software knowledge, to build new software, following the reusability principles.

In computer programming, Intentional Programming is a programming paradigm developed by Charles Simonyi that encodes in software source code the precise intention which programmers have in mind when conceiving their work. By using the appropriate level of abstraction at which the programmer is thinking, creating and maintaining computer programs become easier. By separating the concerns for intentions and how they are being operated upon, the software becomes more modular and allows for more reusable software code.

<span class="mw-page-title-main">Catalyst (software)</span> Open-source web application framework

Catalyst is an open-source web application framework written in Perl. It closely follows the model–view–controller (MVC) architecture and supports a number of experimental web patterns. It is written using Moose, a modern object system for Perl. Its design is heavily inspired by frameworks such as Ruby on Rails, Maypole, and Spring.

<span class="mw-page-title-main">Dave Thomas (programmer)</span> British computer programmer

Dave Thomas is a computer programmer, author and editor. He has written about Ruby and together with Andy Hunt, he co-authored The Pragmatic Programmer and runs The Pragmatic Bookshelf publishing company. Thomas moved to the United States from England in 1994 and lives north of Dallas, Texas.

In computer programming, redundant code is source code or compiled code in a computer program that is unnecessary, such as:

In computer programming, duplicate code is a sequence of source code that occurs more than once, either within a program or across different programs owned or maintained by the same entity. Duplicate code is generally considered undesirable for a number of reasons. A minimum requirement is usually applied to the quantity of code that must appear in a sequence for it to be considered duplicate rather than coincidentally similar. Sequences of duplicate code are sometimes known as code clones or just clones, the automated process of finding duplications in source code is called clone detection.

Rule of three is a code refactoring rule of thumb to decide when similar pieces of code should be refactored to avoid duplication. It states that two instances of similar code do not require refactoring, but when similar code is used three times, it should be extracted into a new procedure. The rule was popularised by Martin Fowler in Refactoring and attributed to Don Roberts.

In software engineering and programming language theory, the abstraction principle is a basic dictum that aims to reduce duplication of information in a program whenever practical by making use of abstractions provided by the programming language or software libraries. The principle is sometimes stated as a recommendation to the programmer, but sometimes stated as a requirement of the programming language, assuming it is self-understood why abstractions are desirable to use. The origins of the principle are uncertain; it has been reinvented a number of times, sometimes under a different name, with slight variations.

In computer science, robustness is the ability of a computer system to cope with errors during execution and cope with erroneous input. Robustness can encompass many areas of computer science, such as robust programming, robust machine learning, and Robust Security Network. Formal techniques, such as fuzz testing, are essential to showing robustness since this type of testing involves invalid or unexpected inputs. Alternatively, fault injection can be used to test robustness. Various commercial products perform robustness testing of software analysis.

<span class="mw-page-title-main">Sandi Metz</span> American software engineer, author

Sandi Metz is an American software engineer and author. She is the author of Practical Object-Oriented Design in Ruby. Metz teaches workshops around the country for new and experienced developers, emphasizing good programming habits and practices.

References

  1. ↑ Hunt, Andrew; Thomas, David (1999). The Pragmatic Programmer : From Journeyman to Master (1 ed.). US: Addison-Wesley. pp.  320. ISBN   978-0201616224.
  2. ↑ Dave Thomas, interviewed by Bill Venners (2003-10-10). "Orthogonality and the DRY Principle" . Retrieved 2006-12-01.
  3. ↑ Object Oriented Software Construction, 2nd edition, page 63
  4. ↑ Pai, Praseed; Xavier, Shine (2017-01-31). .NET Design Patterns. Packt Publishing Ltd. ISBN   978-1-78646-186-5.
  5. ↑ Justin Lee (2006-03-08). "DRY is for losers" . Retrieved 2013-08-31.
  6. ↑ Zig Zichterman (2002-08-08). "JavaOne 2002: Zig's Notes" . Retrieved 2024-01-09.
  7. 1 2 Kent C. Dodds (2019-04-01). "AHA Programming" . Retrieved 2021-05-08.
  8. ↑ Sandi Metz (2016-01-20). "The Wrong Abstraction" . Retrieved 2021-05-08.
  9. ↑ Bartholomae, Daniel (21 August 2020). "Moist code - Why code should not be completely DRY". The Startup CTO. Retrieved 11 November 2021.
  10. ↑ Haus, Ev (24 December 2020). "Using DRY, WET & DAMP code". Medium . Retrieved 11 November 2021.
  11. ↑ Fields, Jay. "DRY code, DAMP DSLs". Jay Fields' Thoughts. Retrieved 11 November 2021.
  12. ↑ Resnick, Brian (28 April 2016). "Why do so many people dislike the word "moist"? This scientist has a theory". Vox Media . Retrieved 11 November 2021.
  13. ↑ Dodds, Kent (27 March 2021). "3 Minutes with Kent: Write the code first, then make the abstraction". Briefs. Retrieved 11 November 2021.
  14. ↑ Dodds, Kent; Bostian, Emma; Nisi, Nick (30 July 2021). "JS Party – Episode #186: Getting hooked on React". The Changelog. Retrieved 11 November 2021.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.