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

Comments

The OpenBSD code is studly.

[Anonymous Coward]

If you haven't looked at it already, you should glance through the OpenBSD source code. 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.

[Anonymous Coward]

You know.. I've run across a particular bug in the OpenBSD source code on at least two occasions. Specifically, NULL is being treated as a null character.

Now, there's some bit of wiggle room for OpenBSD, since NULL can be either:

#define NULL 0

or

#define NULL ((void*)0)

(or something equivalent, like 0L, etc).

Anyway, I presume OpenBSD uses the first definition, because otherwise a diagnostic is required when void* is assigned to a char. If NULL is defined as 0, an unfortunate coincidence allows it to be assigned to chars, since 0 is the null byte.

However, it's still bad code. It's not portable (which OpenBSD might not care about), but it represents an ignorance of the language. There's really no reason to do something in a non-portable manner when it's just as easy to do it portably; who knows, perhaps in the future OpenBSD's C library maintainer will realize that defining NULL to be (void*)0 has advantages and the application will not build; or at least not build without diagnostics.

If the OpenBSD developers like using a macro instead of an unadorned zero, it's easy enough to make one yourself. Though many people find '\0' to be sufficiently self-documenting, much in the way that writing NULL is self-documenting, when you compare it with writing a zero.

In short:

char *pointer = NULL; /* Portable, self-documenting */
char *pointer = 0; /* Portable, perhaps not as self-documenting */
char character = '\0'; /* Portable, self-documenting */
char character = 0; /* Portable, perhaps not as self-documenting */
char character = NULL; /* NOT portable! Try with GNU C library 2.5 (probably other versions too) */

(the comments would line up nicely if I knew anything about HTML)

gcc will whine about a conversion without a cast on the last one; that doesn't mean a cast is the way to fix it, though! Odds are it will work but there's no guarantee and it's just not pretty, especially when both of the examples above it are legal.

If you want to see this bug in OpenBSD, check src/usr.bin/cvs/history.c.

I have no desire to report the bug to OpenBSD, because there appears to be a much better than even chance that the reply will be hostile and childish.

Re:People hate my gotos

[ben_rh]

That's still better as a for { } loop. Apart from it's concise variable initialisation and post-loop statement, for is while.

for (i = 0; not bail_condition; i++) {
    for (j = 0; not bail_condition; j++) {
        inner loop
    }
    outer loop
}

Re:People hate my gotos

[Jaime2]

I think part of the problem might be that compilers have a hard time figuring out gotos. GOTO doesn't imply any scope transition and the compiler has to figure it out. However, BREAK is very clear on which scope is being abandoned. Also, a goto will always compile (well, it depends on the language), but a break with a label will only compile if used in a sane manner.

BTW, I met a guy whose biggest dissapointment with VB.Net was that they did away with GOSUB. I shot him.

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

[Anonymous Coward]

holy shit. as I copied that over to try it (uh, "in a vm", right), I noticed it's even better than you posted it! Here it is fixed-width:

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


Now that's beauty!

Re:Java - nah

[julesh]

This site's primary concern seems to be java

Huh? Are you looking at the same site as me? I count 10 articles, of which:

1 is about the design of a core Java API
1 is about implementing a library in C
3 are completely language independent
1 is about a development environment called "Subtext" which has its own language
1 is about Haskell
1 is about the book discussed
2 are about object-oriented design, and use Java in example code (but the text of the article applies equally to any object-oriented language)

That doesn't seem to be particularly Java-focussed to me.

Re:This just reminds me of my friend.

[AgentBif]

I think to many, part of the beauty of a remarkable haiku is the skill of the writer in packing big, powerful ideas or images into very few words. The haiku form is especially challenging because you have so little space to work with. It is wordcraft... and good wordcraft takes a lot of skill and effort.

In a way, it's like appreciating a remarkable skateboard trick or an amazing touchdown catch because not everyone has the skill to do those things, especially the outstanding examples.