Great code is simple. Simplicity is the cornerstone of all the other attributes of beautiful code - ease of extension, ease of understanding, often even efficiency or at least amenability to optimization.
Following marcus's lead on this one, I don't presume to know what elegant code is. For me its like watching your favourite athlete in action and striving emulate that in your self. So I find rather then reading books on how to write great code, reading the code of people who have made great programs (when you have the opportunity) is an invaluable way to learn. And alot of fun too!
It is a matter of taste and opinion though. We had a programmer at our office who used to use strings for everything. Any datatype, he'd use a string anyway.
He thought it made things uniform and easy. So he'd probably feel the urge to rewrite everything. That doesn't mean it's bad code, it just means he has issues :)
Try rewriting more often :) Rewriting is a form of active reading, and I find active reading helps in comprehending code just like any writing. A lot of the benefits of the whole XP/refactoring movement may come from just this phenomenon, that writing code helps swap a program into one's head more effectively than just reading code.
:) There's something to this. When you have to read your own code a lot of it lingers still, so it's often easier to hold in your head. Importing other people's code into your head is usually more effort, proportional at least to project size regardless of how well-written it is.
If you're talking nuts and bolts coding, and if you read one book about what makes quality imperative code, read Code Complete. In my experience, when people read it, they change the way they program in profound (and good) ways.
In quality code, the cost of changing the code grows more slowly than the benefits.
Everything else flows from this: functionality, readability, clean design, appropriate technology to problem, appropriate effort spent on problem, availability of programmers who can work on such a system, management of legacy features, and foresight of problems and opportunities in the future. Lame 10-line bash scripts that even repeat a few lines can be quality code. And so can entire application frameworks coded in C++.
The Agile people might say that the cost should instead be proportional. They would argue that if extension of the system is too easy, you probably overspent on the initial quality. But I feel in my bones that this is wrong. We should really be aiming for a polynomial or exponential ratio of benefits to cost.
Most of the comments here are in regards to maintainability and conciseness. There are comments like: quality code is elegant. But saying that code is "elegant" is the same as "quality".
Can the person who writes the code be the authority on whether it is quality code? If one of the most important aspects of quality code is how easy it is to maintain or extend. Shouldn't it follow that code shouldn't be considered good until it's maintained or extended.
The Java API's are wildly inconsistent. Some are pretty good, but some (Calendar, Date, IO) are massive trainwrecks that even some of Java's architects don't like. Joshua Bloch gave a presentation somewhere on effective API design where he ragged on Calendar.
And the Design Patterns and Refactoring should be considered starting points, not the be-all-and-end-all of programming. Every programmer should be familiar with them just for the vocabulary. But there are better examples of programming in SICP, On Lisp, Programming Pearls, and TeX: The Program.
My examples and suggestions are limited for Java/C#. The reason why I pointed out Java API is such that people can see which part has a good clean code and which part has inconsistent design.
I'm not currently programming in functional language so I can't really say how much SICP and On Lisp help people to write better software. To my understanding, despite the praise of LISP for clean code, the statement mostly come from experience developers with years of flight-time. I began to question whether LISP actually helped them much given their extensive experience.
Paul Graham (or insert any bloggers that praised LISP) said LISP helped him code in a better way (and etc etc etc) but Paul Graham never program in Java so how do we know if his LISP experience actually help the way he programs in OOP?
Other experience developers said Scheme helped them to have clean code but then again, they threw that statement after x-number of projects in which I'm sure they've learned a lot anyway.
