Don't repeat yourself
Joey Scarr (Talk | contribs) |
|||
| (2 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | Don't Repeat Yourself (DRY) is a maxim aimed at reducing redundancy (and therefore increasing maintainability) in software systems. It was formalised as a design principle in ''The Pragmatic Programmer'' ([[Andrew Hunt 1999]]). Dave Thomas explains it nicely on [http://www.artima.com/intv/dry.html this web page]. | ||
| + | |||
| + | :"DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation." | ||
| + | |||
| + | Note that this does not mean that there cannot be more than one representation of every piece of knowledge, just that one should be authoritative and unambiguous. Often it is necessary to duplicate representations for reasons including performance, eg caches, and readability/programmer convenience, eg compiled object files duplicate the knowledge in source files. Such duplication should always be mechanically reproducible (ie, ./update-cache.sh and it's magically fixed), and generated from the One True Knowledge Item. | ||
| + | |||
| + | |||
== Refer To == | == Refer To == | ||
* [[Once and only once]] | * [[Once and only once]] | ||
Latest revision as of 08:10, 19 October 2010
Don't Repeat Yourself (DRY) is a maxim aimed at reducing redundancy (and therefore increasing maintainability) in software systems. It was formalised as a design principle in The Pragmatic Programmer (Andrew Hunt 1999). Dave Thomas explains it nicely on this web page.
- "DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation."
Note that this does not mean that there cannot be more than one representation of every piece of knowledge, just that one should be authoritative and unambiguous. Often it is necessary to duplicate representations for reasons including performance, eg caches, and readability/programmer convenience, eg compiled object files duplicate the knowledge in source files. Such duplication should always be mechanically reproducible (ie, ./update-cache.sh and it's magically fixed), and generated from the One True Knowledge Item.
