I kind of agree with @garagecoder.
There is a current trend that code must be readable (and well documented!) to be worthy of consideration. And this simplistic idea has made its way in the software development world.
Although this is indeed a desirable property in many cases (team development and so on…), the readability of a code is ultimately only a very minor aspect of the “value” of a program.
For example, if I want to do something quick, only for me, knowing that I won’t go back to it in 2 years or even 2 weeks, and I use a clever way of solving my problem. That’s not bad code, even if the variables I use are named a, b and c.
That would be clearly better than having a very well documented code with fancy variable names that takes forever to solve the same problem, because the algorithm used there just sucks.
Evaluating the quality of a code under the only aspect of its readability is in my opinion a serious mistake.
Would it mean that all programs participating in code obfuscation contests would be considered “bad”? This is exactly the contrary : those are treasures of ingenuity and creativity that only a few talented programmers are able to achieve.
Don’t get me wrong : I don’t say code readability is a bad practice.
It’s just not the only measure to consider chen evaluating the quality of a code.
I think that developers too much focused on the readability of the code should do a small internship of 2 or 3 months doing assembly programming, it would open their mind 