Best Programming Practice Rules

1. Follow the guidelines. Apple provides documents that describe safe coding practices for both Mac OS X and for tailoring applications to be universal binaries. You'll save yourself a lot of effort by studying and following the coding recommendations that these documents provide.
2. No warning messages discipline. When you build your application, the compiler shouldn't generate warning messages. While some of the warnings may seem trivial, they also hint of trouble lurking in the code. All problematic code should be examined carefully and revised to eliminate the warning messages. The BBEdit engineers have a strict policy on not allowing any warning messages during a code build.
3. When compiling, more is better. Like a patient seeking a second opinion for a subtle malady, often a developer will seek a second opinion on the quality of an application's code by building it with a second (and even third) compiler. The other compiler, through its warning messages, can point out subtle coding problems overlooked by the first compiler. Rich Siegel puts it concisely: "More compilers result in higher quality code."
4. Examine the code, line by line. This is the hardest process to follow, but it is probably the most important. During each migration of BBEdit, the engineers scrutinized every line of code in the application. Such careful examination of the code not only identifies what code needs to be revised to support the port, but it also discovers subtle code issues not uncovered by rules two and three. It's also valuable for winnowing code whose purpose has been taken over by a new API or system service. The change in BBEdit to save its preferences using an API rather than a custom resource was the result of this examination.

—T.T.