The biggest problem with professional programmers entering the field is in my opinion precisely the lack of ability to reason about how given code meets the criteria you mentioned and how different versions of the code score using those criteria. Many people have a very hard time at all explaining why they choose to do something one way over another. You have to work on a single project for a long enough time to be able to see how your decisions from one year earlier affect the current code base to learn to do this well.

For the most part, this is a good list.

However, the addendum about performance optimization is (A) not even directly related to code beauty, let alone a requirement for it, (B) a goal that tends to, in practice, come with a price tag of uglier code, and most importantly (C) a call-to-arms for premature optimization.

The paragraph at the very end is a good example of when you should optimize for performance: when parts of your code base are unacceptably slow. It's the impact on user experience that's the problem, not something intrinsic to the beauty of the code.

The idea that your code cannot be beautiful unless you use system knowledge to optimize it "within an order of magnitude [of] the most performant possible code", before you even know there is a noticeable performance problem with it, is bad advice.

Indeed - the last part about performance is the complete opposite of typical code beauty - it's why I listed it separately yet still called it very important when considering code beauty. I disagree that it is bad advice - I have seen code that matches the first 6 standard points yet was bad code because it performed terribly. Simply making pretty and understandable code is not good enough if it's actively harming the users of the system.

The key issue here is that you can have code that does perform within an order of magnitude that still fully follows the first 6 points. I'd argue that this code is inherently more beautiful than code that completely throws performance out the window - it is grounded in the reality of the physical universe.

For example, pretty code that loops through a large array multiple times when it could be changed to loop only once is, in my opinion, fairly 'ugly'. It's throwing out the user's experience (he might have to wait 0.1 of a second more on that button press - annoying!) for slightly easier to read code.

Obviously this is a line in the sand and you could argue either way, but whenever discussing code beauty I always bring up performance as they are often two sides to a coin and both are important. I agree with you that throwing out code beauty and optimizing everything is very bad - but you need a balance here. 'We will fix it later when performance becomes a problem' nearly always ends up as 'We will rewrite the performance critical parts of the code - customers are complaining!' - and now all of your pretty code is lost.

EDIT: Slow performance is also one of the prime indicators of code quality that a user can see. If code performs poorly, a user is likely to perceive that code as being badly written (and I think he is correct). Perception is reality, and when that user is deciding between two systems, he will be biased towards the faster one as he now believes that system to be of higher quality (even though the code on that system is a buggy mess that he just hasn't tripped yet).

> The idea that your code cannot be beautiful unless you use system knowledge to optimize it "within an order of magnitude [of] the most performant possible code", before you even know there is a noticeable performance problem with it, is bad advice.

I disagree, but the key phrase here is "within an order of magnitude." I don't think it refers to squeezing out CPU cycles but rather to choosing the right general solution.

Using a cursor in sql when you don't need to is ugly programming whether or not the specific module has a real-world performance problem or not. Similarly, looping multiple times through a singly-linked-list when a hashset was called for is ugly code as well, regardless if that particular method has a significant real-world effect on performance.

I'm not sure we really disagree here except on semantics. Choosing the right data structure or language idiom for the job at hand isn't premature optimization, at least not the kind that should be avoided, and it's essential to beautiful code IMO.

a comment on items 4 and 6: whilst I totally agree with it, from my experience, many programmers decide in advance what might be used in a more generic sense, and end up generalizing code that is effectively used once or twice. This means in some cases that instead of reading one function to understand what's going on, you have to jump through several files to understand the whole thing...

My personal rule of thumb is that if some pattern repeats 3 times or more, I would consider it boilerplate, and refactor it into a separate library/function. Before that, it's not enough to make a 'rule' out of one or two occurrences.

Very much agree with this. It seems like a sort of analysis paralysis that specifically affects some programmers. Reminds me of a HN post a while back actually by someone who was passionate about building games, but ended up generalizing into building game engine tools, then graphical tools, etc., eventually spending years building ever more general tools, without making any real progress toward his true goal.

You can write your code with modularity in mind, without necessarily having to completely decouple and generalize everything. Once it becomes sufficiently beneficial for a particular module, the refactoring then shouldn't be too onerous.

(Regardless, this 'beautiful code checklist' is fantastic.)

I'd summarize this way: Code Might Suck, But It Still Works (better than your beautiful unlaunched stealth project).

Beautiful code works, and everything else is refactoring.

This post by Ole Lensmar perfectly aligns with your idea of "beautiful" software: http://blog.smartbear.com/software-quality/bid/275689/What-M...

I could not agree with #5 any more. I can't tell you how many times I see default parameters being set incorrectly (i.e. defaults to a corner case so you have to set it on every call). It creates code that looks like:

foo( $data, FALSE, FALSE, FALSE, TRUE );

That drives me nuts.

That code example completely breaks rules #1, #2, and #3 completely. There are probably a lot of ways to refactor that code so that it's still specific. The most common method is to define constants for each value and then pass them in as 'flags' to the method. For example:

  foo( $data, Foo.NEVER_USE_CATS | Foo.DRAW_SQUIGGLIES );

This pattern lets you add in new parameters easily and makes it very clear what parameters are being passed to any function and set sane defaults. This style is widely used in Android to good effect.

It doesn't make code beautiful to run (nearly) as performant as possible. These are two different things.