Clean and Readable Code
Clean and Readable Code
Table of contents
A good code must satisfy few requirements: it must produce correct results, for which it is written. Also, it should be readable and understandable by other developers. It should also follow few code principles. This is your professional responsibility that the code you write will be re-read by many other developers, who want to either understand or modify the code.
Why is this important?
When the code is not readable, the engineer modifying the code, will spend lot of time to understand the code itself. If it is misunderstood, then they will spend multiple iteration to fix his newly written code. Sometime, it can lead to breaking functionality in somewhere else unintentionally.
In another scenario, engineer failing to understand the code, will rewrite the code again, deleting the old code. It has a impact on the overall schedule, customer delivery, most importantly if any corner cases missed, this will lead to more effort. Code should be written to minimize the time it would take for someone else to understand it
Another important aspect, incorrect code and unreadable code. The incorrect code will not be able to hide for long time. Unit-test and automation will be able to detect this very quickly unless these are dead code, while unreadable code can exist in system for long time till the time a new engineer modify this code due to bug fix or new enhancement.
A good codebase - is the foundation of company’s growth. a good codebase consists of well tested and readable code. It helps to increase the confidence to engineer. They will be happy to enhance and extend existing codebase to add more features. It helps company to grow more business.
What do we achieve?
On the surface, readability may seem subjective. Something which may vary between languages, codebases, and teams. But when you look underneath, there are core elements within all code which make it readable.
Can you follow and understand (not read) your code? Does your variable’s, function’s naming convention and functional building blocks follow proper sequence? Are your comments adequate enough for future readers? Are the code style consistent?
Many programmers are too close to the computer. If the code runs, nothing else matters. Although a common defense it removes all of the human elements from what we do.
The readable code starts with you. After you finish your coding, take a break and re-read the code again with a open mind. If you find any shortcomings in your code to make it more descriptive, please add. This will help future readers. In fact, this is a general rule in code review guidelines that another engineer, who is not expert to the codebase, should review the code also. He will look into the code from a fresh perspective. If you and the other developers/reviewers (including the non-expert engineer) are happy with the code and its structures with no open questions, then that is the readable code.
We are in the world of agile, faster customer engagement. Non-readable code — It will indirectly impact project schedule and customer delivery. This is one of the contributor of technical debt. Especially in agile methodology, not necessarily, the same engineer will work on the same module for future work, a different engineer should be able to enhance the code without any additional complexity.
Principles
Few principles of readable code:
- Well-Tested In my opinion, this is very important. well-tested code can be modified without the fear of breaking any functionality. Without tests, risk will come in future work estimation.
- Optimization vs Readability, Always write code that is simple to read and which will be understandable for developers. Because time and resources that will be spent on hard readable code will be much higher than what you get from optimization. Still there are use-cases where optimizston are required, then try to make it like independent module with 100% test coverage.
- Architecture First Writing code, without thinking of its architecture is a bad practice.
- Well Structured, In any codebase (big or small), well structure code is very easy to understand and browse.
- Keep It Simple, Don’t write complex code. Make it simpler than more bugs it may have and less time needed to debug them.
- Thoughtful Naming, Variables, functions, class names will help to understand the code better. This needs little cautious effort from developers to make it happen. You have to make it a practice.
- Comments, Again this itself explains the need of it. A ‘why’ comment is good enough. Make sure it is precise and compact.
- Automation, First and foremost is manual tests. The Automation is needed to make the reduction of effort in long term. If you have the automation ready for your existing code, the effort required to test your existing feature will be very small, only additional testing required for your new functionality.
LEAVE A REPLY