Collective Wisdom from the Experts 159
The more sophisticated tools, such as Splint for C or Pylint for Python, are
configurable, meaning that you can choose which errors and warnings the tool
emits with a configuration file, via command-line switches, or in your IDE.
Splint will even let you annotate your code in comments to give it better hints
about how your program works.
If all else fails, and you find yourself looking for simple bugs or standards vio-
lations that are not caught by your compiler, IDE, or lint tools, then you can
always roll your own static checker. This is not as difficult as it might sound.
Most languages, particularly ones branded dynamic, expose their abstract syn-
tax tree and compiler tools as part of their standard library. It is well worth
getting to know the dusty corners of standard libraries that are used by the
development team of the language you are using, as these often contain hid-
den gems that are useful for static analysis and dynamic testing. For example,
the Python standard library contains a disassembler which tells you the byte-
code used to generate some compiled code or code object. This sounds like
an obscure tool for compiler writers on the python-dev team, but it is actually
surprisingly useful in everyday situations. One thing this library can disassemble
is your last stack trace, giving you feedback on exactly which bytecode instruc-
tion threw the last uncaught exception.
So, don’t let testing be the end of your quality assurance—take advantage of
analysis tools, and don’t be afraid to roll your own.