97 Things Every Programmer Should Know

(Chris Devlin) #1

(^158) 97 Things Every Programmer Should Know

Take Advantage of

Code Analysis Tools

Sarah Mount

TALUEHE V OF TESTiNG is something that is drummed into software devel-
opers from the early stages of their programming journey. In recent years, the
rise of unit testing, test-driven development, and agile methods has attested to
a surge of interest in making the most of testing throughout all phases of the
development cycle. However, testing is just one of many tools that you can use
to improve the quality of code.

Back in the mists of time, when C was still a new phenomenon, CPU time and
storage of any kind were at a premium. The first C compilers were mindful of
this and so cut down on the number of passes through the code they made
by removing some semantic analyses. This meant that the compiler checked
for only a small subset of the bugs that could be detected at compile time.
To compensate, Stephen Johnson wrote a tool called lint—which removes the
fluff from your code—that implemented some of the static analyses that had
been removed from its sister C compiler. Static analysis tools, however, gained
a reputation for giving large numbers of false-positive warnings and warnings
about stylistic conventions that aren’t always necessary to follow.

The current landscape of languages, compilers, and static analysis tools is very
different. Memory and CPU time are now relatively cheap, so compilers can
afford to check for more errors. Almost every language boasts at least one tool
that checks for violations of style guides, common gotchas, and sometimes cun-
ning errors that can be hard to catch, such as potential null pointer dereferences.

Free download pdf