 Beautiful code?
started 1/24/2001; 8:38:44 PM - last post 1/26/2001; 7:11:10 AM
|
|
Chris Rathman - Beautiful code? 
1/24/2001; 8:38:44 PM (reads: 979, responses: 4)
|
|
| Beautiful code? |
|
Since we were discussing whether reading code should be a pleasurable experience, I thought the above discussion was relevant. As with all things Slashdot, there is a bit of cruft but it does show some of the dynamics involved in the aesthetic assement of code.
Personally, I'm more enamored with the ideas behind the code and how well those ideas were captured. Maintainability and extensibility rather than beauty is the overriding concern - though they tend to be related.
Posted to "" by Chris Rathman on 1/24/01; 8:40:07 PM
|
|
|
|
andrew cooke - Re: Beautiful code?
1/25/2001; 12:48:17 AM (reads: 1003, responses: 0)
|
|
|
I seem to have constant low-level warfare with colleagues over what makes code "beautiful". Apart from making it look nice (which means using space *carefully*!) simple design seems to underlie beauty. In particular, I can't understand why people like optimizations - they invariably involve compromising encapsulation (I'm thinking of things that share data rather than efficient algorithms), which screams out "ugly". Yet people seem to find it impossible to resist "optimizing" code before profiling...
Going back to a previous thread, in Okasaki's data structures book, the simple code is clearly elegant (the red/black tree is a revelation if you've ever programmed it in C). It's probably not as efficient (I'm talking constants, not factors of n) as hand-tuned C, but frankly, who cares?
More beauty and less speed!
|
|
Ehud Lamm - Re: Beautiful code?
1/25/2001; 2:16:23 PM (reads: 1008, responses: 0)
|
|
- Maintainability and extensibility rather than beauty is the overriding concern - though they tend to be related.
- More beauty and less speed!
For me beauty and maintainability always seem to go together. Speed usually seems to come for free when your design is right. Most optimization I see tend to produce slow code. Esp. these days (optimizing compilers, RISC). Even optimization hacks can be beautiful if done right.
What I seem to be saying is that only if you are not enlightened do these goal seem conflicting. I think your comments quoted above, are actualy also in this spirit.
|
|
andrew cooke - Re: Beautiful code?
1/26/2001; 12:31:40 AM (reads: 988, responses: 0)
|
|
|
I understand what you're saying (see my conclusions below), but simplicity does involve some compromise with efficiency - the problem comes when people start emphasising efficiency way too much.
For example - this is what I particularly had in mind - Java has a reputation for being inefficient at generating objects. So if you're obsessed with efficiency you start looking for ways to reduce object creation, which tends to imply less encapsulation, static methods and general madness.
So I agree that a good design can be simple, elegant and reasonably efficient. But "reasonably" tends to mean that "big O" is correct; people fussing about the constant factor make things messy.
A better approach is to leave optimisations 'til last, which makes it a lot easier to improve the code (since you're working in a simpler system) - I suspect thus can, in the end, lead to a little localised nastiness (a little less elegant) and a faster final result.
|
|
Ehud Lamm - Re: Beautiful code?
1/26/2001; 7:11:10 AM (reads: 984, responses: 0)
|
|
|
A better approach is to leave optimisations 'til last
This would also be my approach, in all but very specific cases. Of course, deciding which cases these are, is a matter of taste and experience.
God is in the details.
|
|
|
|