This is the Eleventh Step towards gaining the Programming Enlightenment series. If you didn’t learn the Tenth Step, read it.
“The ratio of time spent reading (code) versus writing is well over 10 to 1 … (therefore) making it easy to read makes it easier to write.” ~ Uncle Bob.
We often fall into this infinite loop of reading re-reading the code, time and again. This happens when we are new to a code base which is poorly written, even though it’s working as expected. The time spent in development is way lower in comparison to reading the code.
Observe the following code snippet
if (portfolioIdsByTraderId.get(trader.getId())
.containsKey(portfolio.getId())) {...}What do we understand from it. Nothing can be inferred what the particular method does. We have to dig into the declaration of portfolioIdsByTraderId to understand what it does after spending some time on that particular declaration.
Again observe the following code snippet
if (trader.canView(portfolio)) {...}We can directly infer that if trader can view than it handles the method. The logic whether trader can View or Not is part of trader’s business, we don’t need to care much at this moment.
Which code base do you want to read?
The idea is by making it more clean code, we make it a readable code. With OOP, we got the power of user-defined types. These gave us the domain concepts like Trader, Portfolio, which has different data structures than what platform provides like bits, bytes, arrays and strings.
All of these user-defined domain objects must have data types which define them in real-world. To port them to platform level data structures and making it explicitly understood is the aim of making it readable code.
The inner working of such user-defined data types is the platform provided data structures but we need to encapsulate it with user-defined domain typed one. This not only makes it easier to read, but also easier to test.
How to know if you’ve written readable code?
- Get a self Code Review and see the changes because Self Assessment is the best assessment.
- Put it up for Peer Review, and get feedbacks. It’s always great to have a second pair of eyes.
- Comeback to the code after some time, and see if you understand what you did. If YES, it was readable otherwise refactor it.
- Check whether it follows S.O.L.I.D and D.R.Y principles.
TL;DR The programmer who comes along a few months later to work on the code will thank you. The programmer who comes along a few months later might be you.
Go to Tenth Step.
Go to the Twelfth Step.
References:
- 97 things Every Programmer Should Know ~ Git Book
- 97 Things Every Programmer Should Know ~ Paperback
- Clean Code~Blog
- Top 15 best practices for readable codes ~ Website
- How to know if you’ve written a readable code ~ StackExchange
