What is DRY code?

dry is an acronym for don't repeat yourself it originally comes from the book The pragmatic programmer while it's commonly associated with code the author is actually intended dry to refer to knowledge in your software in general and knowledge can take many forms it could be your code but it could also be something like your comments your documentation or data models knowledge in software is inherently going to change over time you're going to have new requirements that come in you're going to have new features that you need to implement and the more places that knowledge exists the more places you're going to have to update as knowledge gets duplicated it also starts to independently evolve which starts leading to contradictions in your software and an unmaintainable mess this leads us to the core idea of dry any knowledge that you have you want a single authoritative representation in your system let's take a look at some practical examples the first situation is pretty straightforward you've got a function and in that function fun you've got a little bit of duplicated logic in this case say it's parsing some strings into numbers from a query parameter what you can do is you can take that logic into a common function and have everybody call into it now you can also apply this at a macro level say for example that you've noticed that you have billing logic in three different parts of your system and the billing logic happens to be pretty tricky because there's a lot of payment processing involved what you could do is pull that out into a single reusable Library so you're in en capsulating that knowledge in a single place I do think dry is a good principle to follow because with it you're going to get less duplicated code and an easier to maintain code base that said there are a few tradeoffs I think you should be aware of first you're going to be introducing layers of indirection to your code now to understand some code you have to both understand it as well as the shared functions that you're calling into second you have the potential to be introducing additional layers of abstraction to your codebase so let's say that you create a common library to solve a problem that common library has to be generic enough to work for all the different situations in your codebase where you're going to use it and often this can require you to create new data models and new interfaces that work in all those different situations third you're going to introduce a degree of coupling to your system because now you're introducing a new dependency across your code base I think the benefits of dry you usually outweigh these tradeoffs but I also think it's important to just not blindly apply the principle principles like dry their guidelines their heris STS their rules of thumb that usually will get you to the right answer as a shortcut but if you just blindly apply them into every situation without understanding their intent and their tradeoffs you have the potential to misapply them so let's take a look at a few ways that you could potentially misapply dry the first situation is drawing too soon leading to Hasty abstraction so in this situation you make something common before you truly understand the problem and so what you end up creating is not really reusable so as an example let's say that you're the first person to work on billing for your software and so you decide that you're going to take what you've built and make it a reusable Library so it can be used in the future the problem is you haven't seen billing enough to know what those situ ation are and so you can end up building something that is not reusable so this comes up so often that there are actually acronyms to counter dry in these situations the first is wet short for write everything twice or aha which is short for avoid Hasty abstractions you might have also heard of something called the rule of three which was the idea that you should wait until you've written something the third time before refactoring and making it common because it's only at that point that you've truly understood the problem now again keep in mind what I said earlier about rules of thumb and heris and not blindly following them because it applies to these two the second situation is forcing dry so this is a case where if you take different parts of your cbase and you squint and kind of look at them funny they're may be kind of sort of similar and so what you decide to do is refactor them out into something common and shared the problem is they weren't really the same and now you've just kind of Tangled two unrelated pieces of knowledge together and made it harder to understand what's happening the last situation is mistaking duplicate code for duplicate knowledge this is a situation where code happens to look similar but it really is encapsulating different knowledge so for example let's say that we have logic to validate whether a user can upgrade and another one of whether a user can get a discount today the code may look the same but it is likely that that is going to diverge in the future because they represent two different pieces of knowledge so to recap dry is an acronym for don't repeat yourself the core idea is to make your system more maintainable by making sure that every piece of knowledge has a single authoritative representation it does have trade-offs like indirection and abstraction and coupling but in most cases these tradeoffs are worth it that said Dry like rules and principles should not be followed blindly or you have the potential to misapply them and one of those situations that you should look out for is drawing too soon leading to Hasty abstraction as always I hope this was useful if you'd like to see more content like this please consider liking and subscribing and with that I'll catch you next time

Channel: Scott Bailey

Views: 5,314

Keywords: software development, software engineering, dry code, pragmatic programmer

Id: HwTcjWtDAfc

Length: 5min 50sec (350 seconds)

Published: Mon Mar 18 2024