Any "Pretty" Code Out There?

andhow writes "Practically any time I hear a large software system discussed I hear "X is a #%@!in mess," or "Y is unmanageable and really should be rewritten." Some of this I know is just fresh programmers seeing their first big hunk o' code and having the natural reaction. In other cases I've heard it from main developers, so I'll take their word for it. Over time, it paints a bleak picture, and I'd be really like to know of a counterexample. Getting to know a piece of software well enough to ascertain its quality takes a long time, so I submit to the experience of the readership: what projects have you worked on which you felt had admirable code, both high-level architecture and in-the-trenches implementation? In particular I am interested in large user applications using modern C++ libraries and techniques like exception handling and RAII."

Comments

OpenSolaris

[jlarocco]

As large and old as it is, OpenSolaris has fairly readable code. Plus, most of it has comments explaining why it's done the way it is.

Re:Hello World

[MillionthMonkey]

Not so secure when the company is sued for stealing source code. He took credit (with his copywright notice) for a very old joke. A blatent copy-and-paste. One has to wonder how much of that he does on the job.

Ha ha, joke's on you, you dick- that "old joke" was written by me five years ago as part of a larger post and I was not at work- in fact it was way after hours and I was about to go home. I just started with the base concrete implementation and this is what it looked like after a few minutes of stuffing patterns into it- Singleton, Factory, and Strategy. I keep thinking one of these days I'll release a 2.0 version with Proxy and Bridge. Since I was the original author I retain the right to paste it wherever I want and to attach any license agreement I feel like attaching.

This has become the most famous code I've ever written which is the sort of thing that makes you reflect on your career. So far it has netted me about 20-30 karma points over the years (lord knows how much karma was gotten from pirated copies). I found it being examined in some software engineering papers and it even made its way into one of the patterns books (as an example of "Patterns Happy" code). When I found out about that, I made the guy send me a free copy and acknowledge me in print so I can maybe net some jobs unnecessarily screwing up simple code with GoF patterns which always pays well. Now that I released it under the terms of the Apache license he might come back for his book.

Re:Comments lie. Code never lies.

[cburley]

I'll comment (inline) as someone who has come to appreciate certain of qmail's strengths even while tolerating (to varying degrees) its weaknesses:

I thought it was hideous. From memory (it has been awhile):

• Hard coded file and folder names (it must be in exactly one location, too bad if you have a need for two outgoing SMTP servers running on the same box with different configurations)

That's annoying, but basically a security feature — you can be reasonably assured that a given qmail executable, especially qmail-queue (which is the only setuid-root program in qmail), is hard-coded to operate on only certain directories (aka folders) and files. And it's not "too bad" if you need to run a second SMTP server; just configure, build, and install as many distinct qmails as you need, with the configuration files (such as conf-qmail, normally /var/qmail) set as you want them. But I think it could be more flexible without sacrificing security assurances.

• Strange homegrown replacement for the standard C library

I gather djb's perception of the situation (at the time he wrote qmail and related software) was such that he'd substitute "Secure" for "Strange" above, but I don't personally know of exploitable bugs in contemporary C libraries, so I can't vouch for that. However, exploitable bugs in C code that uses standard C libraries are well-known, which is another reason I believe he grew his own C library.

• Memory deallocation done by exiting the program

Definite win for security and speed, if you don't have memory-leak problems as a result (and I don't think any qmail component does, modulo known issues with requiring per-process VM limits on Internet-facing components such as qmail-smtpd). As soon as your program starts down the path of calling free(), or, hey, even malloc(), if it can reasonably avoid them, it gets much more complicated and bug-prone, something you don't want in a system as crucial to have working correctly with no exploitable bugs as an email server.

• Odd preprocessor "template" functions

Haven't studied this enough to quite "get" what he was trying to accomplish vs. other approaches that could have been used, but they are doggone annoying to deal with at times.

• A seeming hatred of descriptive variable or function names

Agreed.

I don't have fond memories of the experience.

qmail code is pretty ugly when looked at closely enough, and can seem unnecessarily "different" from a more-distant perspective.

However, pull back far enough and look at it, and you might be able to appreciate that it is, in its own way, a work of art: a reliable, secure, powerful email system — just as pretty much any sufficiently large and beautiful work of art can look pretty flawed when scrutinized closely, especially without an awareness of the "big picture".

So if I wanted to play around with an email server and make it do all sorts of slick stuff, I wouldn't pick qmail.

But if I wanted to improve a mail server in some fashion while still being reasonably assured the resulting (modified) system wouldn't have remotely exploitable bugs in it, based on what I know right now, I wouldn't pick anything but qmail.

Re:Firefox

[TheRaven64]

Are there any operating systems out there that use random numbering of PIDs? OpenBSD randomly numbers PIDs. Malloc and mmap on OpenBSD map pages into a random part of the process's address space too. A lot of work has been done to ensure that an attacker knows as little as possible about a program that they manage to compromise as possible.

For low-grade random numbers use something like /dev/urandom (on UNIX) instead. For high-grade random numbers, use /dev/random and note it may take a while to build the entropy. By 'UNIX' you mean 'Linux.' Other *NIX platforms do not always provide two entropy sources. On OpenBSD, /dev/random is a hardware random number generator, srandom is the strong (blocking if not enough entropy is available) random number generator, urandom is the one which transparently degrades the randomness if entropy is not available, prandom is a simple psuedo-random number generator and arandom is a device for producing seeds for an ARC4 random number generator. On FreeBSD, there is just /dev/random, which is the Yarrow generator seeded periodically from the various entropy sources.

Don't ever hard-code /dev/* into your program unless it's one of the devices specified by POSIX. Last time I checked, this limited it to /dev/null, /dev/console and /dev/tty.