- such a small section of software code that it is almost terse
- very clear expression of the problem it solves
- the use of a technique in a way that surprises the reader
- an intrinsically highly efficient run profile
- trivial special cases or preferably no special cases
Think of the Towers of Hanoi. I don't know if everyone else racked their brain over this problem like I did, or if others had to be led by the hand through the recursive solution - that elegant, recursive solution. Recursion doesn't fit how the problem is described - you just pick up the disks and move them....!
When you see the solution expressed recursively, it surprises you. It's concise. It's tight as anything. It's as clear as air. It's elegant.
Elegance, though, is not a quality to be sought, standardized, or mandated. It feels serendipitous because it is serendipitous. You can't conjure it up for every class of problem. In fact, like the Towers of Hanoi, an elegant solution is often a response to a problem that is rather elegantly phrased itself.
There is a common thread, however, to elegant solutions that we can value and strive for: abstraction. It is abstraction that provides the conciseness, clarity, and efficiency we value in an elegant solution. And in fact, when an elegant solution is proposed, you can vet it directly by finding its abstractions and analyzing them for correctness.
Sometimes we call something "elegant" that really isn't. Correctness is still correctness. Judge the elegant code by its real quality, and create elegant code by emphasizing these qualities.