Stylish Bugs

Summary

Whenever a bug is discovered, it’s immediately apparent that three things have gone wrong. They used the wrong language, and this never would have happened if they’d written it in the bugfree language. They used the wrong development methodology, and this never would have happened if they’d used the prevent this bug technique. And finally, they ignored best practice and didn’t use the proper coding style. The bug would have been extremely obvious if only they’d replaced all v_w_ls with underscores in variable names. Just look at the word v_w_ls. It pops right out.I recently contemplated a new style which seemed intriguing, but let’s begin with a survey of a few coding styles. How will our new contender rank?yodaThe prototypical error free style is putting the constant first in a condition. if (0 == x) prevents mistakes like assignment in the condition if (x = 0). I’ve never used a compiler that didn’t warn on this, however. And the warning also catches mistakes like if (x = y) where swapping if (y = x) doesn’t prevent the problem.I think this is common to coding styles. They only prevent a limited subset of the error class and are typically subsumed by better checks.It’s also interesting that this bug may occur as a result of another style requirement, to always write out expressions. I’d probably just write if (!x) in many cases, but oh no, that’s not explicit, you’re only one character away from doom, we need to write out the full thing.There was an attempt to slip such a bug into linux in 2003. And of course, there’s a comment that you should switch the conditional around, although it’s less clear why a hacker writing directly to the cvs repo would bother following your style.Another security bug was in the X server because they check if (geteuid == 0) without calling the function. Sure enough, all the very smarts had the bright idea that this wouldn’t have happened if only they had followed proper style and written if (0 == geteuid). Nope, that does nothing.So a...