Code Is Communication
Humans use verbal and non-verbal communication.
And so does your code. When you name your functions, variables, properties, etc. — you communicate verbally. You literary embed the meaning of your code — in your code.
But you also communicate non-verbally in your code. This communication happens through the structure of your code. Yes, the structure of your code is a communication method where you, the author, want to say something to those who read your code — your readers. You embed the meaning of your code in the structure of your code.
When we start coding, we learn early on the importance of naming your functions, variable, properties, etc. appropriately. We invent naming conventions to support this method of communication. However, not always we think as much about what our code structure communicates. First, it’s not obvious that our code structure is a communication method and second, it’s not easy to communicate with our code structure.
Just like we have naming conventions for verbal communication in our code, we have software design principles that help us create code structures that communicate our intentions better.
Have you heard of DRY and KISS principles?
DRY is Don’t Repeat Yourself. This principle promotes the idea of writing less duplicate code. When you first adapt this idea, you will start investing extra effort in avoiding writing the same code over and over again. While your intentions are right, you can extend your efforts to the point of avoiding duplicate code at all costs.
And there’re costs associated with applying DRY principle. DRY is not free.
The obvious cost of DRY is investing more of your time and effort into structuring your code in such a way where you can reuse as much code as possible. This leads to writing less code. The hidden cost of DRY is that in your efforts of avoiding duplicated code, you might write code that is more complex than the duplicated one. As a result, your DRY code can increase complexity of your code.
And complexity in your code is your enemy. You gain one benefit and you give away another one. This brings us to the second principle in software development — KISS.
KISS is Keep It Simple Stupid. This principle promotes the idea of writing code that is easy to read and understand by as many software developers as possible.
When you apply DRY and KISS principles in practice, you can run into a situation where those principles conflict with each other and you need to choose one of them.
If you find yourself in that peculiar situation, go for a KISS.
Let’s explore an example.
Let’s say in your code you’re describing a thing, and in your business case — there’re different types of that thing. Each thing is a complete encapsulation of some business rules that are relevant to that thing. None of the things know about each other and as such — they could duplicate certain business rules, unintentionally.
Now you could abstract and reuse those business rules, however, this code reuse would introduce new complexity to your design: now you have things that are not aware of each other, but they depend on abstracted reused business logic that “couples” them together, so they’re not as independent anymore as they used to be.
This code reuse leads to less code, but it adds complexity to your overall code design — change the shared business logic in the future and you might unintentionally break one of the things.
What do you do in this scenario?
Think about what you are trying to communicate with the structure of your code.
If you want to explicitly communicate through the structure of your code that the things are intended to use the same business rules — let them depend on a shared component that encapsulates those business rules. If not — duplicating business rules are fine within different things, as it’s only an accident that the rules are duplicated right now.
This code duplication might change tomorrow.
This is an example of how the intention of your communication with the code structure helps you to choose between applying KISS or DRY principles. Whatever principle you choose, do it with an intention to communicate something about your business rules.
Code is communication.
Whenever in doubt, think what you are trying to say with your code and choose design principles that do it best.
Thanks for reading.
Let me know if this is helpful to you and feel free to ask any follow-up questions.
I offer one-on-one training sessions for those who’re learning React and front-end software development. Get in touch for more details: http://artemij.com
