James's Weblog

I’ve recently spent some time looking at the source code to several open-source projects.

I am appalled.

Here’s a sampling of what I’ve encountered:

• Buffer overflows. I cannot understand how C programmers continue to use gets, strcpy, and strcat when fgets, strncpy, and strncat are available. This isn’t that hard. (The C standard library shares a lot of blame; it never should have provided the unchecked versions, and it at least should have given gets/fgets and strcpy/strncpy consistent behaviors. strncpy and strncat aren’t as easy to use as they ought to be, either.)
• Unchecked errors. Writing error-checking code is hard and a lot of work, so apparently some people decide to forgo it altogether. Woe upon the user.

• Illegal language usage. Apparently a lot of people think it’s perfectly legal in C or C++ to name identifiers with a leading underscore. Often it’s not. Although in practice a namespace clash is unlikely, identifiers with leading underscores can intrude into the compiler’s namespace.

  I’ve also argued (unsuccessfully) with some people who recklessly invoke undefined behavior.

• Unmaintainable code. I suppose that I naively hoped that How to Write Unmaintainable Code was a work of fiction, but yes, Virginia, there are magic numbers. It’s odd that so much open-source code has poor documentation, sparse comments, and cryptic function and variable names. What’s the point of publishing your code if it’s unreadable?
• Inconsistent styles. More readability and maintenance problems stem from projects that lack strong core leadership.

What’s the big deal? The obvious problems are software vulnerabilities and broken software. I think that there might be a deeper problem, however.

Code begets code. Many people learn how to program by looking through other people’s code, and publishing bad code makes it too easy to propagate bad habits and to produce lousy de facto standards. Worse, people might copy-and-paste bad code outright. Yes, it can work the other way too; good code can be a paradigm for others to follow. Unfortunately, the sheer quantity of bad code available makes good code a needle in a haystack. Saturating the planet with immature software projects is not a step forward.

As potential pedagogues, open-source developers ought to be held to a higher standard. Unfortunately, reality offers a contrary opinion. A recent study indicates that email is more likely to be ignored when there are more recipients; are similar factors at play in the programming world? Does the nature of open-source code—where there’s a lack of accountability and where anyone can look at and change the source code—encourage its developers to shirk their responsibilities in the hopes that someone else will clean up their mess? Or are programmers in general just too lazy, too unskilled, too ignorant, or too apathetic? (I’m admittedly not a very experienced programmer; I lack design experience in particular. If nothing else, though, I’m meticulous (so Jeff Wong says) and consistent, and I make a conscious effort to be responsible with what I write!)

(Before anyone gets the wrong idea, I am not an opponent of open-source software. I’m picking on open-source code mostly because closed-source code isn’t available to be criticized.)