What is the DRY/ KISS Principal

If you learned something new feel free to connect with me on linkedin or follow me on dev.to :)

I feel like this is one of those topics in clean coding that doesn't get talked about too much, it's almost as if it's a little old fashioned and yet, once every so often I get asked about it in an interview or it comes up in conversation. So, I'm taking the opportunity to talk about it now.

Both DRY (Don't Repeat Yourself) and KISS (Keep it Stupidly Simple) are software design principals. When followed they can lead to better designed and easier maintained code. Now with adhering to any principals, I have found that they each have a time and a place and that time isn't every-time. The reason I say this is that there can be situations when following them to strictly can lead to unnecessary complexity or even OVER-KILL (think trying to swat a fly with a bazooka). We don't want that.

The DRY Principal
Some might have seen it as WET (Wasting Everyone's Time). To say that something is DRY is to make sure that the code written, is as reusable and small as possible. Code re-usability can be better achieved by introducing abstractions, and by refactoring the code into smaller more manageable pieces. The overall goal should be to reduce, reuse and recycle. The benefits of this is firstly to make the code look better, and easier to maintain. Also it helps to reduce the number of bugs in your software, and should help with identifying where bugs are if any occur. Again it is possible to make something overly DRY such as abstracting an already small object with little reusability, so watch out!

The KISS Principal
Essentially, keep methods small <20 lines. Also each method should do one thing, and only one thing (single responsibility). The benefits of using KISS is that it, again makes your code easier to maintain and also helps with readability. The simpler, more Englishly reading your code can be the better. You are coding so that someone else will read it after all. Easier to read code == easier to maintain. I'd like to think that when writing code if someone looked over my shoulder they should be able to tell what is going on like in a book... well maybe a complex book with variables in it. Also for the love of all things codey, watch out when using magic strings/ numbers. I'd avoid them altogether if you can. And that methods at most have 4 parameters in them, anymore and it is clearly is doing more than what it needs to be or you need to pass in a object that incapsulates the parameters of the method.

In conclusion each principal should be used where appropriate, and each of them should be in the forefront of your mind when developing/ maintaining software.