cory foy put this topic bluntly, “as developers, system admins, and a variety of other roles in IT, we have to deal with code on a daily basis. sometimes it’s just one-off scripts we never have to see again. sometimes we stare at something that, for the life of us, we can’t understand how it came out of a human mind (or, as the book puts it, has a high WTF/minute count). but there is a time when you find code that is a joy to use, to read and to understand. clean code sets out to help developers write that third kind of code through a series of essay-type chapters on a variety of topics. but does it really help?”
i always believe that a clean code is a good code. having had experience as an IT consultant, we come and go to different projects. a critical part in our job is to transition our codes to someone else.
most of the problems however arise when facing messy codes (plus no docos!). in effect, the learning curve takes longer, business cost is higher, and productivity is lower.
so what causes a bad code? from experience, i would list these factors:
time pressure. with limited and immovable due dates, most programmers tend to be lenient in cleaning up their codes just to be able to deliver on time.
training deficiency. not being able to learn best practices,
no coding standards. no standards set from the very start of the development!