This week I have decided to continue with the discussion about design principals from last week. I like design principals because they generally provide important things to keep in mind while coding and are written in a fashion that is easy to remember (typically an acronym of some sort), which is why I’ve continued to discuss them. This week there are three I want to discuss: KISS, YANGI, and DRY. Now, you might be asking, why three? Well, these principals all focus on keeping things as simple as possible, so they kind of go together. Jonathan San Miguel has nice blog that discusses the basics of these principals.
First in the queue is DRY. Don’t Repeat Yourself. Another way of putting this would be to say, “don’t reinvent the wheel”. Have you ever been looking through your code or someone else’s code and realizes that there are similar or identical pieces of code in different parts of the program? Well, following this design principal will help eliminate that. You shouldn’t have to repeat code, and if you do, the original piece should be redesigned so you don’t have to waist your time writing the same thing over and over again. I always find it frustrating when I find similar code because I have to spend time trying to determine if they are exactly the same, why there is a need to have it twice, what is the little variation in it that made them write it twice, etc. So to summarize, unless you have a clear, distinct reason for repeating code, don’t do it.
Next up is KISS. Keep It Simple Stupid. This one is kind of self-explanatory, but basically it means don’t make your code more complicated than it needs to be. Keeping code simpler makes it easier for others to read, easier to modify, and easier to look back to later on. I especially agree with being able to go back and modify later on. At the time, the complicated code you wrote probably made perfect sense to you, but if you go back to it a year later to make some adjusts you may end up asking yourself what the heck you were trying to do with that piece of code for the next two hours. I know I’ve done it. Miguel also suggest avoiding using language specific features. By avoiding this, it can allow other people that aren’t familiar with the language to still understand what is going on.
Last on the list YAGNI. You Aren’t Gonna Need It. If you don’t need a feature at the point in time of writing it, don’t include it. You don’t need it now and you probably won’t need it in the future. You are simple wasting your time and other people’s time as well as probably causing some confusion.
I hope you found these principals insightful and useful. I know I did and will keep them in mind when writing code.
Link:
From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.
