I have been reading about Object-oriented programming because I have had to do quite a bit of that for my project lately. I came across this link:
en.wikipedia.org/wiki/Don’t_repeat_yourself
and decided I wanted to talk about it.
D.R.Y. stands for “don’t repeat yourself.” In this context it is related to the idea that when one codes, one should abstract repeated lines of code into singular functions, ideas, or groups, which can then be evoked when needed and if changed, would affect all instances of its use.
For example, if I wanted to print out the contents of a list to the console, I might use some kind of loop to print each item in said list line-by-line. I might end up in a situation where I need to print out that list again, or perhaps print out a different list instead. I could, if I were being lazy, just repeat the printing loop in my code every time I needed it to happen. However, that would not be very D.R.Y. of me!
Instead, I might write a function to handle printing lists line-by-line for any time that ever comes up. Inside this function I could house the printing loop and all I’d ever need to do to use it would be to call the function and pass the list I wanted printed. Now my code is visually simpler, and if I ever needed to change how I wanted my lists printed, I’d only need to change the function I wrote, rather than every time I wrote out the original abomination.
The chosen antithetical concept to D.R.Y. is W.E.T. which is very shocking, I know. This acronym was retroactively created to be a sort of supervillain for D.R.Y. to fight. It commonly stands for “write everything twice” but has been known to take on other sayings all with the same sentiment.
It evokes all the worst and sloppiest coding practices one could think of. That being said, it could find its way into even the most well meaning and clean code. How? If a project is large enough where you can’t see everything all at once, you can easily begin to recreate processes that have already been written. Making sure to not repeat oneself also requires a conceptual understanding of what one’s program is trying to accomplish and how it is doing so.
Perhaps an addendum or asterisk to apply to D.R.Y. would be A.H.A. which sounds like someone getting an idea. This one stands for “avoid hasty abstractions” which in my mind essentially means that one should be mindful and deliberate any time they are going to compartmentalize something in their code.
I could write a new printing function for every kind of structure I end up using, but that, in a way, is kind of repetitive. What if, instead, I made one king sized printing function that could figure out what I gave it, and printed it out the right way? And what if, later, even three months later, I realized that the kind printer function just wasn’t cutting it? A.H.A. also implies that one should always be open to refactoring their code if it will make things better and neater in the long run.
Quite a lot to think about from three little acronyms!
