Beautiful Code Interview

An anonymous reader writes "Safari Books Online has just posted an interview with Andy Oram and Greg Wilson, the two editors who put together the recent O'Reilly book, Beautiful Code. "Beautiful Code" features 33 different case studies about challenging coding scenarios from some of today's most high-profile developers and OS project leaders. There's also a new Beautiful Code web site based on the book where many of the authors are blogging about their work and coding practices."

Nothing to see here

Yeah, thats about the amount of beautiful code I expect to see in my life time.

Re:Nothing to see here

"If builders built buildings the way programmers write programs, then the first woodpecker that came along would destroy civilization." -- forgot who said it.
 

Re:Nothing to see here

If it's any consolation, you did get the coveted first typo.

hypocritter?

I find it amusing that TFA has tons of html errors.

This just reminds me of my friend.

His introduction to C++ teacher told him throughout the class that his code was not "pretty" because he wasn't properly commenting. The code always worked flawlessly, but still she marked "-1 code not pretty"
On the final project he spent a good portion of time properly commenting all of his code and ended with a commented ascii flower and the following:

//Look at my flower,
//my pretty pretty flower.
//Now my code is pretty

He was marked off "-1 Sarcasm not appreciated"

Re:This just reminds me of my friend.

He should have removed one syllable from the last line; then he would have gotten "+1 haiku!"

The OpenBSD code is studly.

If you haven't looked at it already, you should glance through the OpenBSD [openbsd.org] source code [openbsd.org]. It's truly remarkable how well-written it is. But I wouldn't consider it "beautiful". I think studly is a better word. It's rugged, strong, and built to handle the toughest of the tough.

Re:The OpenBSD code is studly.

Hey Theo ... haven't chatted with you in a while. How's it going ? Family doing well ?

People hate my gotos

But I find goto is often as beautiful as it gets:

for (loop 1) {
      for (loop 2) {
            if (something happens that makes me want to bail on both loops) {
                  goto loop_done;
            }
            do_inner_loop_work;
      }
}

loop_done:

Re:People hate my gotos

Personally, I think that is uglier than goto. Also, I think it's more confusing, because you have this condition repeated twice, and you'd have to have a "break;" in the right spot in the inner loop, as well as some sort of a condition check right after you get out of the inner while loop to ensure the remainder of the outer while loop does not execute once the condition is met. Yes, you can do this a lot of different ways, but you have to torture the while/for syntax to avoid goto.

Re:People hate my gotos

Any crap programmer can write spaghetti code with or without the use of 'goto'.

If goto were not useful or necessary then languages would have dropped it years ago when CS profs started to dread it because they couldn't teach their students properly and got tired of spitting out idiot programmer after idiot programmer who tortured them with goto-ridden spaghetti code.

Telling people to NEVER use goto is like saying "never use a chainsaw because if you attempt to cut down a weed you'll just end up with a big mess". So what, we use a hand saw to cut down an oak tree ? There are far more elegant solutions for a lot of things that can be accomplished with goto. Conversely, there are occasions where goto makes for a more elegant solution.

At the very least, as you put it "beauty is in the eye of the beholder". Using your own philosphy I opt for giving programmers all of the necessary tools that they may find useful, and deciding for themselves which ones to use. After all, there are some programmers out there who could write code that is 100 x more efficient and elegant using ONLY gotos in C with main as the only function than I ever could using goto-free, well designed and thought-out object oriented Java, for example.

No matter what you do, the end result will always be the same anyway. Exceptional programmers will continue to produce exceptional code and pasta chefs will continue to produce spaghetti.

We all use goto, we just call it something else

Which is presumably why languages like Pascal, Java, Python, Ruby, etc. all support goto.

But how many of the above languages support...

• early function return?
• exceptions?
• break/continue/last/next escapes within loops?

goto is like assembly language: it's a flexible tool, but very primitive. Just as higher level languages are more expressive than assembly, meaning we rarely have reason to write raw assembly any more, so higher level languages have developed more expressive versions of goto, meaning we rarely have to write a raw goto any more.

I think someone needs to write a new article, called “Dogmatic structured programming considered harmful”. While block structure with the sequence, iteration and decision operations has proven a useful model for describing algorithms, other powerful abstractions for control and data flow exist. Functional programming tends to use recursion rather than iteration, for example, and many functional languages don't really model sequence in the classical sense either. Almost all modern, general purpose programming languages support the concept of exceptions, which are just a more systematic form of goto. In some programming languages, there is no explicit concept of control flow at all.

I don't see many people who understand these extended or alternative models complaining about how we should go back to doing everything with block-structured, procedural code. We just have to learn to use different models effectively, as functional programmers found before they realised the importance of tail recursion, as OO programmers found before they learned to control stack unwinding. This is called “progress”, and is what happens with experience... unless you adhere dogmatically to the way things are done at the moment, regardless of any objective merit an alternative may have.

Re:People hate my gotos

So what if they compile to the same code? Source code is for humans to read, and machine code is for machines to read. Comments don't show up in the compiled code at all. Does this mean that they serve no purpose?

Break's and goto's are very different, and I am surprised to see so many people say that they are essentially the same. When I am reading code and I see a break statement, I know where the flow goes. When I see a goto statement, I have no idea where the flow goes unless the label is withing a few lines. That is the difference.

Beware the raptors ...

http://xkcd.com/292/ [xkcd.com]

That is all.

Sure...

Programmer - You are sooo beautiful. My masterpiece. My pies de resistance!
[ Kisses screen and compiles code into native instruction set ]
CPU - Hmm. Where have I seen your fugly face before?

The problem with the book...

Anyone else have laugh when they looked at the cover of the book?

A Flock of Birds?

To symbolize beautiful code?

Flock-of-Birds-style code is the UGLIEST code out there!

Used only by those who haven't learned to use case statements, build databases, or define arrays.

Is this beautiful code???

if(something==interesting)
    if(somethingelse==goodcode)
        if(somethingother==blahblahblah)
            if(somestupidbookcover=birds)
                doSomethingUseful();
            else
        else
    else
else
    if(somethingelse==goodcode)
        if(somethingother==blahblahblah)
            if(somestupidbookcover=birds)
                doSomethingUseful();
            else
        else
    else
end if
 

beautiful code

while (1){
Beer b = (Beer)getBeer();
drinkBeer(b);
belch(BelchType.LOUDLY);
}

Most code is beautiful at one point in time

Most code is beautiful at one point in time - namely, when it's first written. A decent programmer can produce some decent code that performs the task at hand elegantly. With a little work this can become beautiful. Most applications I write start out very elegant, beautiful, commented, clever, etc. - It's only after the project grows and I'm working on a file named "main4.3.a.iii.bak2.worksithink.c" that the comments turn into "// why is this here?" and the variables go from "nDBEntryCount" to "temp" and the code becomes an ugly mess.

The real trick is DESIGNING the application in such a way that it can grow gracefully, and STAY beautiful. And that's really tough - knowing what sorts of features and requirements the future will hold is difficult. A big part of this is the language itself - I love assembly languages, and I could write some really clever and beautiful assembly code. But when the requirements change and the code needs a new feature? There goes all the carefully timed loops and cycle counts!

Beautiful code is as much beautiful, expandable, future-proof design as it is beautiful implementation.

I've become jaded

Is anyone else jaded by these books that go on and on about why a particular techique or code snippet or methodology is "right" or "beautiful" or "the way forward"?

I look at some of the code mentioned and yes it's neat. Some of the code snippets from these books (not just this one specifically) is either really obvious or makes me want to blow chunks because it's an over-complication or over-simplification just to demonstrate a technique which you know will be over-applied and end up in some set of corporate standards that sees it being misused. ...then there's some of the frameworks and methodologies out there that are generally worshiped as God's own code, but which when you try to use them turn out to be cumbersome, horrible, unintuitive messes. Years later this is suddenly "discovered" (EJBs I'm thinking of you!!!) and a whole new set of horrible frameworks goes through several iterations (Hibernate 1 vs 2 vs Spring persistence, Struts vs Spring MVC) where nothing is allowed to mature for long enough to have the major bugs ironed out.

Perhaps I'm just getting old but I'm really getting tired of all this. You want to know what makes code beautiful?

1) It does the job 100% correctly as intended.
2) It does it as simply as possible - not so simple it doesn't work, and no more complex than it absolutely needs to be...building everything in but the kitchen sink just in case is a fool's game.
3) It's readable and well documented enough that anyone who knows the language (or better yet a programmer familiar with a similar framework but not this one) understands it.
4) Its easy and quick to make changes as requirements change - that means GUI tools for GUI development (What ever happened to RAD tools being the norm in the industry!? It can take a week to make significant changes to a web page in Struts or Spring MVC, where it use to take about a day to do it for the clients developed with the RAD tools of the late 90s!)
5) It fits in well with the rest of the system. A module that works beautifully in isolation but doesn't fit in with the system can ruin the system.

All the rest is just a bunch of consultants trying to bilk you for cash.

Yes patterns can help, but they can also hurt.
Yes externalizing code into config files can make a system more flexible (but you'll pay for it in readability and tracability/debugability).
Yes aspects of the agile methodology - continual integration and test driven coding - can help but they're not the only way and there's a cost associated.
Yes Object oriented code offers things that procedural does not, but again there's a cost and your developers better understand the language constructs.

You need to look at each of the above as tools in your arsenal, not religious doctrine.

Note that my recent experience is with Java/J2EE so that's where my examples come from but I've worked on dozens of languages and frameworks.

Stupid frameworks.

Ugh, Java frameworks.

Somebody needs to drag the people who make these things in a room, erase their memories, and make them use what they have created. Perhaps then they can start to feel how asinine they can be sometimes. It is as if they get off on how many design patterns, random XML config files, and other "best practices" they can cram into a single framework. "We're switching to using a BuilderFactoryGatewayStrategyFacade." Thanks for the heads-up guys, we were all dying to know exactly how you implemented it! (Don't forget to scatter pattern names all over your code. People have to know you're using them!) All I want to do is integrate such and such framework in with my program. But, no, I have to read the documentation that describes the problem and how exactly to use the framework. Inevitably, they begin spouting off about how "elegant" it is that you can configure exactly which IntFactory to use by hard-coding the classname in a mandatory configuration file that is prone to getting lost at deployment time. (Remember, making objects with just the new operator is a classic beginner's mistake, don't fall prey!)

The end result is you end up with what should be a fairly simple task (like OO-relational mapping) have 400 page manuals because it ends up doing every little thing that people want to do. In the time it takes you to choose the right framework, download and install the binaries, wade through the required config files, sift through the quickstart, and actually get familiar with how it is done, you could have just written and tested the tedious JDBC code to load and unload an object from the database.

But, why do that? There's no hype around that! You're not REALLY an enterprise architect until you have twenty different config files that need to be present just to run your product! If it is an enterprise product, it shouldn't be simple to configure!

All of these products do serve legitimate needs. But the obsessive over-engineering that surrounds them and the religious fervor by which they are declared Good (despite violating the principle of least surprise at every turn) point to fear. A fear that the code you're writing just isn't good enough somehow. The fear that your code is too simple, too straightforward. A worry that that requirement you're meeting is mission-critical, and, mishandled, could threaten the stability of the entire system. This isn't usually the case. It would seem that Java's simplicity sort of drives its hardcore users mad after awhile. What it lacks in expressiveness, people try to make up for by inane configuration and extensibility instead of just sitting down and Getting The Damn Thing Done. Sure, the code is boring. The best code is anything but glamorous.

The most beautiful code I've ever seen...

...looked like this:

not exp log srand xor s qq qx xor
s x x length uc ord and print chr
ord for qw q join use sub tied qx
xor eval xor print qq q q xor int
eval lc q m cos and print chr ord
for qw y abs ne open tied hex exp
ref y m xor scalar srand print qq
q q xor int eval lc qq y sqrt cos
and print chr ord for qw x printf
each return local x y or print qq
s s and eval q s undef or oct xor
time xor ref print chr int ord lc
foreach qw y hex alarm chdir kill
exec return y s gt sin sort split

Simply elegant! My younger brother sent it to me; not sure where he got it. It's Perl, by the way.

Visually and Logically Beautiful

I think there are two kinds of beauty in code: visual and logical. Visually beautiful code is code that is formatted well, easy to skim through, and easy to read. This includes things like defining useful variable/function names and writing understandable comments. Logically beautiful code is code that is designed to fit together well, makes a lot of sense, and leaves no confusion. It expresses its intent in the simplest and cleanest way possible.

I think getting code to be logically beautiful is much harder of the two. It takes a lot of insight to see a simpler and cleaner way of expressing the same thing. To use a math analogy, a coder might get his code to work with this:

F = (0.25 * m * x * a * 4) / x

but not realize that it can be simplified to this:

F = m * a

You can teach people how to be visually beautiful with their code, but when it comes to logical beauty, they either have it, or they don't.

Re:Visually and Logically Beautiful

That isn't true at all. What happens in the second case when x == 0.0 ?

Obligatory comment that 90% of programmers'

code sucks but I (and the 90% of programmers who make this claim) are in the remaining elite 10% that are coding Gods.

My Beautiful Code

10 PRINT "Hello World"
20 GOTO 10

Poetic Code

I purchased the book after reading this recent slashdot thread [slashdot.org], where I believe Mr. O' Reilly mentioned it himself. My degrees are literature and poetry, so I probably have a slightly different aesthetic than most programmers. I'm leisurely working my way through the book and enjoying it. Most the examples provided don't strike me as breathtakingly beautiful so much as intelligent solutions to interesting problems.

One example I do find beautiful, after reading some of the explications of it, was this one mentioned a while back on slashdot:

Origin of Quake3's Fast InvSqrt() [slashdot.org]

I also find the algorithm here beautiful insofar as it elegantly solves a challenging problem that I was working on commonly faced by accountants:

http://www.geocities.com/SiliconValley/Garage/3323 /aat/a_diop.html#diophant [geocities.com]

By the way, for truly poetic code, see the works of Kay Ryan [wikipedia.org]. Or Spenser's Faerie Queene.

OS

["Beautiful Code" features 33 different case studies about challenging coding scenarios from some of today's most high-profile developers and OS project leaders.]

OS as in Open Source or Operating System...
obviously the first, but still.. quite ambiguous.

Java - nah

This site's primary concern seems to be java. Like the GOF, they seem to want to monopolize what is good and beautiful about it and most of all, how to do it. All fine and dandy if you're looking at ambitious eighteen year olds (ambitious to become faceless programmer droids, that is), but there seems to be an awful lack of discussion going on. Besides, currently my concern in _not_ java - so tell me again why this site would bother me ?

Yuk

Found in the examples:

if (/GET \/ongoing\/When\/\d\d\dx\/(\d\d\d\d\/\d\d\/\d\d\/[ ^ .]+) /)

Okay, how in the hell is that "beautifull?"

if ($_ =~ m|GET /ongoing/When/\d{3}x/(\d{4}/\d{2}/\d{2}/[^ .]+) |)

Truly beautiful

The most beautiful code in the world is that block of code that finally gets the shit to compile and build yes yes yes ohhhh thank you thank you god i can go home now wait hold it jesus fuck fucking wait what time is it the clock says its wednesday i thought it was tuesday fucking shit whatever oh shit oh shit shit shit oh shit i didn't call julie again shit shit shit shit shit well thats fucking great ive been here for the last 46 hours and now im finally able to go home to my pissed off wife who will ultimately deny me sex again and make me sleep on the goddamn couch like a goddamn dog. fucking beautiful.

Re:Have to say...

I have yet to see a really good example other than my own.

I, too, am the only one I know who writes decent code.

Re:Have to say...

I always get burned at the stake when I say this, but the biggest problem with OSS that I run into is horribly ugly code with very few useful comments

I struggle with this. When I was in school, my instructors drilled into me the importance of documentation and comments. Now that I've been in the real world, I have to say that I don't agree.

The problem with comments is that you now have two things to maintain, the code and the comments. Often time this is OK for a single developer but for someone coming in to maintain a piece of code, often times they are hesitant to touch the comments especially if they are wrong.

I find that (for me at least) I have the greatest success with short, composed methods that do one thing and one thing well all backed up by unit tests that test behavior and requirements, not simply that foo() returns 15.

You might be thinking that I'm contradicting myself here because now I have to maintain both code and tests. However, I feel that the tests provide much more value in that once a test for a piece of code works, you now have confidence in that piece of code. If you miss something with the test, its a simple matter of adding a new test for that case.

Re:Have to say...

Now that I've been in the real world, I have to say that I don't agree.

I have to respectfully say that if you believe this, you haven't written 1) enough code, and 2) complex enough code, to have filled up your brain sufficiently to where you can't remember what the hell you were thinking at that time. When you've reached that level of programmer maturity, THEN you will understand the importance of comments. :)

Never mind trying to blaze the trail for programmers that come after you. I also predict that you haven't tried to unravel another programmer's crappy code.

The problem with comments is that you now have two things to maintain, the code and the comments

Yes. People who change code but don't update the comments should be flayed appropriately.

I find that (for me at least) I have the greatest success with short, composed methods that do one thing and one thing well all backed up by unit tests that test behavior and requirements, not simply that foo() returns 15.

Testing and commenting are two different subjects. Comments are not to tell you that "foo() returns 15", comments are to tell you the *context* of code, how it fits in with the overall goal of the subroutine.

Re:Have to say...

The problem with NO comments is that debugging can not determine wither code is correct - it can only find whether two representations of a solution are equivalent.
...
So a good programmer writes TWO versions of his program - in representations as different as possible. (Preferably one optimized for automated translation, one for human readability.) That way he's thinking in different mindsets, greatly reducing the likelihood of making identical errors in both representations

Who cares about identical errors, you're screwed either way then. The big problem is when the "documentation" and the "code" don't match ... you have no idea which one is wrong.

As the old saying goes: "The man who has a watch knows what time it is, the man who has two is never sure." ... of course the man who has one watch and a big pile of unit tests which prove it's keeping the right time is doing the best of all :).

I've been at this for a pretty long time now, and I've found very little use for "comments explaining what the code does" ... but a lot of use for "comments explaining why". And personally, I've gone back to code I've written over 5 years ago and could see what it was doing instantly ... and on the bad side I've read code I wrote a year or so ago and not understood why it was doing something (to be fair, after thinking about it a bit it became "obvious" ... but then I wrote a comment explaining it anyway :).

Yes, I've read others peoples code that (in theory) would have been easier to understand if it had been heavily commented ... but it would have been even easier to read if they'd just been any good at what they were doing and written the code well.

Re:Have to say...

I don't know why you'd single out open source, this applies to code at large. I think it's just one of those '90% percent of everything is crap' things.

Re:Have to say...

I always get burned at the stake when I say this, but the biggest problem with OSS that I run into is horribly ugly code with very few useful comments.

The sad thing is, as far as I can tell, this is true for the vast majority of closed source code as well. You just don't tend to see closed source code as often...

Re:Beautiful Code

Where are the Test-Case Discussions. Beautiful code needs testcases that are the same.

Perhaps in chapters 6 and 7?

Re:For 876344

87362 38726 88872 61726 67672 88872 13102 91228
77798 77798 15882 13232 54060 54060 18577 00000

You fucktard! That string caused Windows to send an "I dump you" IM to my significant other.
       

Re:Beautiful code

IE if it takes you 2 years to write beautiful correct code that is maintainable and works perfectly AND your project is two years late to market **you still suck**

If it takes 2 years to write the code and you're 2 years late to market, you really need to find another market.

Re:atari 2600

Atari games contain very ugly code, but how many people can say they wrote code that sold over 100,000 units at a penny per byte?