Code has style when you can't describe why the code is so good. Because when you try to describe it, you know you're selling it short - the code is more than si

Code has style when you can't describe why the code is so good. Because when you try to describe it, you know you're selling it short - the code is more than simply its specification. The only way to convey the quality of the code is by reading the code itself. Code has style when you'd rather read the code than an explanation of what it does. For me, it's always a matter of simplicity. When a problem is hard to describe in English, you naturally assume the code will be a bit complex as well. And yet, sometimes, the problem can be decomposed so neatly that the parts are trivial and fit together effortlessly. For me a requirement is that after carefully reading the code you are absolutely certain there is no room left for bugs. You almost know for certain that the code didn't have any bugs when it was written down for the first time, because it captures intent so well. If you need to refactor it's probably too late already. So I think books like "Beautiful code" got it entirely wrong. I especially don't agree with icey's opinion that refactoring can make code tasteful or that linebreaks can make or break greatness. It's about bringing human thoughts to computer code. And when that mapping is perfect, the code is great.