I’ve recently spent some time looking at the source code to several open-source projects.<\/p>\n
I am appalled.<\/p>\n
Here’s a sampling of what I’ve encountered:<\/p>\n
gets<\/code>, strcpy<\/code>, and strcat<\/code> when fgets<\/code>, strncpy<\/code>, and strncat<\/code> 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<\/code>\/fgets<\/code> and strcpy<\/code>\/strncpy<\/code> consistent behaviors. strncpy<\/code> and strncat<\/code> aren’t as easy to use as they ought to be, either.)\n\t<\/li>\n- \n\t\tUnchecked errors.<\/strong> Writing error-checking code is hard and a lot of work, so apparently some people decide to forgo it altogether. Woe upon the user.\n\t<\/li>\n
- \n
\t\tIllegal language usage.<\/strong> 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<\/a>.<\/p>\n\t\tI’ve also argued<\/a> (unsuccessfully) with some people who recklessly invoke undefined behavior<\/a>.<\/p>\n<\/li>\n- \n\t\tUnmaintainable code.<\/strong> I suppose that I naively hoped that How to Write Unmaintainable Code<\/a> was a work of fiction, but yes, Virginia, there are magic numbers<\/a>. 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?<\/strong>\n\t<\/li>\n
- \n\t\tInconsistent styles.<\/strong> More readability and maintenance problems stem from projects that lack strong core leadership.\n\t<\/li>\n<\/ul>\n
What’s the big deal? The obvious problems are software vulnerabilities and broken software. I think that there might be a deeper problem, however.<\/p>\n
Code begets code.<\/strong> 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.<\/p>\n