Laws are for kids.
Don’t eat that from the floor. Wash your hands before dinner — Laws.
But when we get older we learn the principle behind them:
Hygiene is good for your health.
Just like kids dipping their toes in the waters of a whole new world, when we learn to program we learn some basic rules that allow us to write good code. At that point we may not even know what good code is, but we are told that some practices are good and others are bad and so we roll with it… just like kids.
But which are the principles behind the laws that we learned and repeated time and again? When on doubt, can we turn to just a handful of premises that will guide us through the right path? I think we can!
They are also known as software qualities. But I like to think about them like principles because of the timeless aspect to them.
Flexibility and Extensibility
Flexibility is the ability of a system to adapt when requirements change. Extensibility is the ability of a system to grow with ease when new requirements and functionalities are needed.
To think in terms of flexibility and extensibility, next time you are working on something, stop for a moment to think about what the future requirements might be. Then ask yourself, what would it take to incorporate this new requirement? Or how much effort would it be if this functionality changed in X way? How likely is it to happen?
With some knowledge about the problem you are solving you will know to an extent what the future holds for your system.
But how are they related to the rules we’ve been taught? Think about these two:
- Don’t repeat yourself aims for flexible code. Because making changes to a codebase with repeated code is hard and error prone.
- Keep it simple allows us to write easier-to-extend programs.
At the end of the day the goal of perfecting your programming skills is to build software that will be easy to work with in the long run. This is why you will find these principles sitting behind every good coding practice.
Readability might be the most important coding principle and the easiest to remember and apply. It is so important that I often like to think about it like the mother of every good coding practice out there.
Consider for example just these two:
- Give variables and methods meaningful names
- Prefer short methods over long ones
They are highly beneficial because they take readability into account.
After all, writing code is about communicating solutions. If you just use one letter variables or if you take the time to choose meaningful, expressive names for them, will be all the same to the computer but not to the ones working with your code later on.
Why all of this matters
Making a stand for quality will help us to fight the biggest issue we face when programming complex systems: maintainability. And knowing the core reasons for what we practice is a fundamental part of it.
Take code review for example: on that instance there’s little benefit on saying that some code is “pretty” or “ugly”. But I’ve found that whenever someone makes a conscious effort to talk in terms of readability, extensibility and such, code review can become a great instance for learning and reinforcing the coding principles that the team holds most valuable.