Lots and lots of talk about 'good', very, very little talk about elegant. Not to mention the ridiculous remarks about XOR. I find more often than not that those who have never at lest dabbled their hands in assembler tend to miss a number of things that they might otherwise appreciate. Elegance is one of them. Until you code without, it is hard to see how well something is at a higher level. But that is just the rant of someone who has been at this since the 70's :)
It always strikes me that the top voted answer in this type of discussion just replaces one adjective (elegant) with other adjectives (simple, succinct, readable). "Elegant" appears to be a combination of other, more fundamental aspects which need to be defined to know what elegance means.
So how do we define "simple" and "readable" and what tools do we use, other than years of experience, to achieve simple and readable code. I think that's the more fruitful debate.
Aidan Cully's answer has some meaningful content: http://programmers.stackexchange.com/questions/97912/how-do-... It's also pretty close to my answer, except I would say that he gets bogged down in visual complexity and I'm more interested in the more empirical concerns of information content. Assuming "good" style, a solution that is minimal, contains only essential complexity, and nothing more, is elegant.
Languages differ in their general elegance by virtue of their ability to separate essential complexity from accidental complexity. For instance, C is hobbled in the contest to create truly elegant code, because in its capacity as "portable assembler" you can't ever really ignore memory management, which is in the accidental complexity domain for the vast bulk of problems.
It always makes me think of Hemingway and his ability to never use more words than necessary to say something, and at that, always the words that say it best.
It should be noted that Hemingway's fifth rule "5. Write one page of masterpiece vs. 91 pages of garbage." doesn't infer writing complex sentences, but emphasises not using 10 words when 1 will do.
Agreed, there is a pretty good discussion over on the portland pattern repository that echoes your take: "Elegance" really just means "has a lot of nice properties". So, when someone claims 'elegance', you should stop them and ask for clarification on the precise properties or features they are examining.
The thing I'd say about "elegant" is that elegance achieves some combination of desirable characteristics so well that it stands out as a noticeably better solution. If you can use three somewhat obscure lines to do what someone else take five readable pages to do, you're elegant even the code isn't that readable.
That said, since true elegance is kind of exceptional, it probably shouldn't be the criteria for acceptable code - "clear, readable and reasonably" is a better standard to have.
Elegant code is code that has a minimum of visual complexity that captures the necessary complexity of the problem.
The key thing to realize is that elegance is necessarily a property of the medium. An elegant solution to a problem written communicated through text will be different than one communicated audibly, as there are different mental facilities available for understanding said code.
I will add that your first glance at the code should give you the same feeling that you get when you see a hot sports car or an Apple product[1] for the first time. Humans are attracted to visual appeal and code is no exception. Code that looks visually appealing is the code you are going to enjoy maintaining.
[1] I realize Apple's design is not everyone's taste, it's just an example.
I believe that good code is understandable, consistent, and easy to edit. This is because we basically do three things with code, which correspond to the above: read it, integrate it into projects, and change it/add to it.
If code is written that satisfies these properties AND solves a problem efficiently, then it is elegant for being useful and easy to work with at the same time.
1. All entities named in a way that describes their purpose as precisely as possible. Prerequisite: a design that carves the problem into concepts clear enough to permit precise naming.
Agree on the naming, though it always brings to mind Tim Bray's quote: "There are only two hard things in Computer Science: cache invalidation and naming things"
Not "as precisely as possible" but "as precisely as necessary".
For example, "i" is great name for a loop variable. It keeps it from distracting you and it saves space so you can see more of the variables whose names matter.
23 comments
[ 0.28 ms ] story [ 49.9 ms ] threadSo how do we define "simple" and "readable" and what tools do we use, other than years of experience, to achieve simple and readable code. I think that's the more fruitful debate.
Languages differ in their general elegance by virtue of their ability to separate essential complexity from accidental complexity. For instance, C is hobbled in the contest to create truly elegant code, because in its capacity as "portable assembler" you can't ever really ignore memory management, which is in the accidental complexity domain for the vast bulk of problems.
It always makes me think of Hemingway and his ability to never use more words than necessary to say something, and at that, always the words that say it best.
Someone else picked up on the similarity between the Hemingway rules for writing well and parts of the UNIX philosophy: http://unix-simple.blogspot.com/2011/03/unix-and-hemingway.h...
It should be noted that Hemingway's fifth rule "5. Write one page of masterpiece vs. 91 pages of garbage." doesn't infer writing complex sentences, but emphasises not using 10 words when 1 will do.
source: http://c2.com/cgi/wiki?ArgumentByElegance
That said, since true elegance is kind of exceptional, it probably shouldn't be the criteria for acceptable code - "clear, readable and reasonably" is a better standard to have.
> Code I wrote yesterday. (As opposed to "six months ago," which is how I'd define "crap code.")
The key thing to realize is that elegance is necessarily a property of the medium. An elegant solution to a problem written communicated through text will be different than one communicated audibly, as there are different mental facilities available for understanding said code.
[1] I realize Apple's design is not everyone's taste, it's just an example.
If code is written that satisfies these properties AND solves a problem efficiently, then it is elegant for being useful and easy to work with at the same time.
2. Well-factored at all levels.
For example, "i" is great name for a loop variable. It keeps it from distracting you and it saves space so you can see more of the variables whose names matter.
Compare the number of identifiers in
to (Those are not exactly the same function, but I hope you can see them as idiomatic expressions of the same idea.)