Hello. It’s Boggarak again.
This is the second part of the Good Coding Practices series that I am making, which covers coding practices that you should be applying when you are coding, from making Roblox Games to making a Java program. Last time, I went over when you should make a comment in your code, and, if you haven’t read that yet, then click here to read it. I heavily recommend that you do, as it will come in handy when you are coding.
This time, I am covering one of the more well-known coding practices that is usually taught, and that is the DRY principle. To fully understand what this principle is and how to use it, I will use an (non-coding) example that will hopefully demonstrate the main idea behind this principle is.
Example
Let’s say you are making an enemy or a mob for a Roblox RPG, for instance. Since you think you are done with the enemy, you copied and pasted it throughout the map
Let’s say that there was a bug with it, or that you wanted to modify it’s abilities so that it isn’t too easy or too difficult. Regardless of the reason, you wanted to modify the enemy in some way. Well, since you have copied and pasted the same enemy multiple times, you will either have to modify every instance of the enemy, or remove all the other copies and copy-and-paste again. This, as you can tell, can be a bit frustrating or even time-consuming, depending on how much you have copied and pasted the same enemy.
Well, there is actually a better way to do this: make a spawn for the enemy, which is relatively easy to code and debug, and copy and paste that instead. So, if there happens to be a problem with the enemy, or you want to change it in some way, you only need to modify only one instance of that enemy, instead of wasting your time on modifying multiples.
What you just did is the main idea behind the DRY principle; the DRY principle is the idea of never copying complex (and bug-prone) code multiple times, and, instead, have a single instance of that code in a function (or method, for Object-Oriented programming), and copy and paste that instead (via function calls).
Misconceptions
The “DRY” part of the DRY principle is short for “Don’t Repeat Yourself”, which is actually a bit misleading, since the main idea behind it involves copying and pasting a function call, or variable name depending on the situation. Someone might get wrong ideas about the principle from just the name alone, like never copying or pasting a single line of code, even if it is just a single function/method call.
There is one way where this principle can go haywire is when people take this principle to the extreme; people might try to put any copied code into a function/method, even if it doesn’t really need to. To check whether or not a given pieces of code needs to be centralized into a single location, see if the following would apply to the code (the more points it satisfies, the more justified applying the DRY principle to it will be):
- Will the code be present in multiple locations (either within the same script or in multiple different scripts)? This is the most important part to consider. If this doesn’t apply, then ignore the following lines:
- Does the code consists of multiple lines (i.e. more than 3-4 lines of code)?
- Will you want to modify this code later on (like seeing if it works as it is intended)?
- Is the code complex (more complex code will be more likely to be prone to bugs and unintended consequences)
Again, there are exceptions to this, and you need to be the judge of when you should this principle, as it can easily make the code more messy if it is used more than it really needs to.
That is really all I have for now, although I will add more stuff here if I think it would be useful. If you guys have any suggestions on what should I add here, then feel free to add them. This post, along with the other posts I have made, will be modified over time to make them as good as they can be for people learning how to code.
For now, see you next time when I will cover Big-Oh notation, which can help you determine how fast your algorithm is.
References (Recommended)
Previous Post: Good Coding Practices I - When You SHOULD Make a Comment in Your Code