3 ms·

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 requi

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.

RyanZAG 14y ago
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).
deleted 14y ago
[deleted]
DavidWoof 14y ago
> 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.

RyanZAG 14y ago

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).

deleted 14y ago

[deleted]

DavidWoof 14y ago

> 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.