I guess "clean code" is in the eye of the beholder. A lot of my work involves supporting scripts written in an extremely terse language (q http://code.kx.com ht

I guess "clean code" is in the eye of the beholder. A lot of my work involves supporting scripts written in an extremely terse language (q http://code.kx.com http://code.kx.com). Coming from a Java background, the code looks horrendous, incomprehensible even. But the language is designed for the analysis of a huge amount of data using concepts from linear algebra. Any attempt to re-write the code following the tradition "Clean Code" recipe could result in inefficient code. I think there is a sweet spot for each application or domain, somewhere between the efficient (but unreadable), "clean" (but posssibly inefficient) axis. This sweet spot depends on the tools, the problem set and constraints that the developer is working under.