4 ms·

There has recently been a huge uptake on 'make code beautiful' all over the place. The main thing the beauty seems to emphasize is variable naming and other ina

by RyanZAG 14y ago

There has recently been a huge uptake on 'make code beautiful' all over the place. The main thing the beauty seems to emphasize is variable naming and other inane surface level driftwood. This stuff is not what makes code beautiful and any code can be converted to look like this with simple formatting tools. Judging code on being 'good' or 'bad' based off whether someone hastily dumped it through a neatness format tool is a terrible precedent. Code is beautiful if 1) Accomplishes the goal it has to perform in an easily understandable format. 2) Is designed in a way that modifying one part of the code will have minimal/no impact on other parts 3) Is named well enough ('self documenting') so that the amount of comments can be kept to a minimum 4) Hides as much boiler plate code inside helper functions/libraries as possible so that the real logic is not lost in a sea of boiler plate. 5) Is specific enough that 'tricks' are not required to use it for the intended purpose. 6) Uses generalized code in common areas - and has this generalized code moved to external libraries for maintenance and re-use across projects. And very importantly (but often missed in this case): Uses system knowledge to optimize code to run as well as (within an order of magnitude) the most performant possible code for that problem can run. Systems can be as beautiful as they want, but if your OS takes 15 minutes to boot or your FPS game runs at 2 fps (and as people are beginning to notice: your web app server can only handle 50 users), all of your beautiful code is wasted and should be thrown out.

Baustin 14y ago
This post by Ole Lensmar perfectly aligns with your idea of "beautiful" software: http://blog.smartbear.com/software-quality/bid/275689/What-Makes-Beautiful-Software http://blog.smartbear.com/software-quality/bid/275689/What-M...
stiff 14y ago
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.
mikegioia 14y ago
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.
- RyanZAG 14y ago
  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.
rtfeldman 14y ago
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).
NoPiece 14y ago
I'd summarize this way: Code Might Suck, But It Still Works (better than your beautiful unlaunched stealth project).
- rhizome 14y ago
  Beautiful code works, and everything else is refactoring.
gingerlime 14y ago
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.
- tempestn 14y ago
  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.)
pekk 14y ago
It doesn't make code beautiful to run (nearly) as performant as possible. These are two different things.

by RyanZAG 14y ago

Baustin 14y ago

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

stiff 14y ago

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.

mikegioia 14y ago

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.

RyanZAG 14y ago
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.

rtfeldman 14y ago

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

NoPiece 14y ago

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

rhizome 14y ago
Beautiful code works, and everything else is refactoring.

gingerlime 14y ago

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.

tempestn 14y ago
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.)

pekk 14y ago

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