Ensuring higher-quality code

Reading Microsoft’s Many Eyeballs and the Security Development Lifecycle by Shawn Hernan has revealed some interesting practices that I should want to apply to my own personal programming efforts:

• Static Analysis
• Dynamic Analysis
• Fuzz Testing
• Code Reviews

Most of this was grabbed from Microsoft's Security Development Lifecycle which included several other practices, but these seemed to be the best for a small team with a small budget working on a relatively unknown project that hasn't been seen by many users.

Static Analysis

Static analysis seems to me to be particularly handy in a one-man operation, since what it involves is running the code through some checks to make sure that everything is on the up and up. A good example is lint for C, Microsoft has a free one that works for .net apps, and Java has several good free ones like Checkstyle and FindBugs, but what about C++ developers? I'm thinking about trying out CppCheck, one of the several suggested by Stack Overflow #141498. Remember though, that not every bug listed is a true bug, there can be many false positives.

Dynamic Analysis

Dynamic analysis is also another useful tactic even in a one man project. Unlike static analysis, which looks at the code, dynamic analysis inspects the program when it is running. The best open-source example I can think of here is valgrind. This technique also has the same false positives issue that static analysis has.

Fuzz Testing

I first heard of fuzz testing when I read about one of the ways Google Chrome checks for errors. Other articles explain it better than I do here, but the gist is that varying amounts of random data are shoved into your program, and then you look at the results. For web apps, it would be random webpages or random text. For games, it could simulate mashing down on a keyboard or something. A quick search on Google revealed one open-source automated tool, zzuf, designed mostly for video and web apps.

Code Reviews

Shawn Hernan's article noted that code reviews are useful and do catch bugs, but not as many bugs as when both static and dynamic analysis are used. This has a problem with single developer projects because you need at least one other developer to review the authors code. In that case, the best the developer could do, I guess, is to wait a month or two and read the code again. Google Code has peer reviews built in, and I know SourceForge also has the option. If you have code on your own server, I've had great luck with Review Board.

In conclusion, when it comes to personal projects, these things I just mentioned are the least sexy concerns when it comes to development. We care about features and having them as soon as possible. I have yet to even start using them here at team pezad, but I have an interest to, because 1: It will make the programs more reliable and therefore friendly to its users and 2: It will make me a better programmer, and I'd like to think more marketable as well.

Squish the bugs, and you'll have more room for richer, healthier features. That's my theory!