How Do You Define Elegant Code?(programmers.stackexchange.com)
programmers.stackexchange.com
How Do You Define Elegant Code?
http://programmers.stackexchange.com/questions/97912/how-do-you-define-elegant-code
11 comments
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.
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.
Agree here too.
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.
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.
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.
source: http://c2.com/cgi/wiki?ArgumentByElegance
source: http://c2.com/cgi/wiki?ArgumentByElegance
Ahhh, thanks for the link. That page brings back two cherished memories: the C2 Wiki and the indefatigable TopMind!
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.
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.
I enjoyed this commenet:
> Code I wrote yesterday. (As opposed to "six months ago," which is how I'd define "crap code.")
> Code I wrote yesterday. (As opposed to "six months ago," which is how I'd define "crap code.")
Yep, I've always thought that if my code from six months ago isn't crap, then I must have stopped learning.
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.
2. Well-factored at all levels.
2. Well-factored at all levels.
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"
I thought the quote went: "There are only two hard things in Computer Science: cache invalidation, naming things, and off-by-one errors."
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.
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.
Yes. Though I like languages that help me to eliminate meaningless identifiers.
Compare the number of identifiers in
Compare the number of identifiers in
sum :: [Integer] -> Integer
sum = foldr (+) 0
int sum (int size, int* array) {
int res;
for (int i = 0, res = 0; i++; i<size)
res += array[i];
return res; }
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.
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.
[1] I realize Apple's design is not everyone's taste, it's just an example.
Like beauty, pornography, or simplicity -- you know it when you see it.
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 :)
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.
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.
I like this cartoon: http://www.osnews.com/story/19266/WTFs_m
"If you are out to describe the truth, leave elegance to the tailor." -- Albert Einstein
Possible duplicate of http://stackoverflow.com/questions/563036/what-is-elegant-co...
How do you know a beautiful woman when you see one?
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.