Raja Nagendra Kumar outlines FOUR habits to clean coding
Firstly, whenever we say ‘DONE’, it is not actually from the business angle. Expect a lot of problems to come in, and handle them i.e. what we should keep as the scope of ‘done’, rather than the project manager declare it with whatever information I give.
Most of the time what actually happens is – from the definition of the process once it is done, there is a lot of bugs, regressions and fires. All these are actually telling you where the gap is in the ‘DONE’. The philosophy of a clean coder should be “ Don’t enjoy fire and never be in in fire”.
The best way to clean coding, is to understand issues as opportunities, treating bugs as inputs to make code better. At some point you will achieve, ‘Nirvana’ where you see the code you’ve written is actually scaling well, performing well, is able to adopt to new changes very well. That is my definition of clean code, rather than trying to measure it as a metric.
So, as long as you’re able to control the fire by a certain structure of the code, you are achieving clean code and there is a great benefit for a product to evolve faster.