Take Advantage of Code Analysis Tools
Sarah Mount THE VALUE 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. 158 97 Things Every Programmer Should Know 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.
，有理想在的地方，地狱就是天堂
