Don't Repeat Yourself (DRY)
2025/12/27
- Type
- Learning Resource
- Format
- Glossary Article
- Version
- General
- Subject Tags
- Created
- Updated
- 2026/02/16
- 2025/12/27
Don't Repeat Yourself (DRY)
Don't Repeat Yourself (DRY) is a popular principle in software development that aims to reduce repetition in code. The DRY principle states that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."
In simpler terms, you should avoid duplicating data or logic in your project. Instead, you should group important data and logic into components or locations that are accessible by all the systems that need it. This way, if you need to make a change, you only have to update it in one place, reducing the chances of introducing inconsistencies caused by duplicated elements.
For example, if you have items in your game, you should have a single database, place, or file that defines all the item types. This way, your shop, inventory, and dialogue systems can all access the same database. When designers add or remove items, everything can access the updated data.
DRY is a very sound idea, but one you don't want to take too far. Practically speaking, you don't want to make every small piece of code generic and reusable just to avoid repetition. Doing so can lead to code that's more abstract and difficult to understand.
A good rule of thumb is that if you repeat the same code three times in your codebase, you may consider refactoring it into a reusable function or module. However, if you only use a piece of code once or twice, it's often better to keep it where it is to avoid over-engineering your solution.
Also, when you have two scripts that look similar but are not quite the same, it's often a good idea to keep them separate rather than making shared code that will likely be more complex to accommodate the slight differences.
I apply this principle in gameplay code by considering a "piece of knowledge" as one of the game's mechanics or entities.
For example, if I work on an indie game with different flying mobs that have unique movement and attack patterns, I will not necessarily try to make a generic
FlyingMobclass that can handle all of them. Unless the game is so large and involves so many people that it calls for a reusable system.Having unique code for the patterns of each mob can make the code more readable and much easier to debug and maintain as the logic is specific to that mob.
Nathan
Founder and teacher at GDQuest
As with many general programming principles, you must use your judgment and experience to decide when to apply the DRY principle and when to avoid it.
The goal is to avoid a situation in which a single component of your codebase is repeated in multiple places and, when changed, requires updating in multiple instances.
This is error-prone because as the codebase grows, it's too easy to forget to change one of the instances, which can lead to bugs that are hard to track down.
