This is the fifth installment in a series of describing the components of a typical development environment. The previous installments and their links: Part 1 (Text Editors), Part 2 (Interpreters), Part 3 (Compilers), Part 4 (Linkers).
Using the previously mentioned tools you can write a program and run it. There are some tools that help ensure the program is correct, and if not, find out why. The type of tool we’re looking into today helps with the former, but not necessarily the latter.
Static Code Analyzer
Just like the interpreters, the compilers, and the part of the text editor which provides syntax highlighting, static code analyzers need to have knowledge of the programming language you’re using.
The main use they have is detecting common pitfalls that lead to errors and point them out to the programmer. A slightly less critical use is making sure that your code complies with a set of (sometimes aesthetic) guidelines, commonly called coding conventions.
The oldest program of the kind that I know of is Lint, which was built to statically analyze code written in the C programming language.
The reason this tools exist is that the rules that define a programming language’s structure aren’t always neatly mapped out in our minds; we make assumptions about the language’s we’re working on, and sometimes that can lead to mistakes. When we accumulate enough of these, we can write a program which reads our code and identifies them.
As they need to know about the language, they tend to be language specific. Here’s a list of some static code analyzers:
- pylint; which is made for the Python programming language.
- TOAD; which works with several SQL dialects.
- SonarQube; I’m specially fond for this one, because, along with some automated build software, it made me start working towards better programming habits and more predictable code
There’s a counterpart to static code analyzers: static object code analyzers. I’ve not personally used one of those, but I guess that common pitfalls may be identifiable at this level, such as potential buffer overflows.
On the other hand we have dynamic code analyzers; this category covers profilers and debuggers – the latter of which are, incidentally, the subject for Tomorrow’s post.