Python

Among the various Python linters (Table 3), Pylint is undoubtedly one of the classic static code analyzers. On request, the tool checks code for compliance with the PEP 8 Style Guide for Python Code. Pylint also helps with refactoring by tracking double code, among other things. On request, Pylint generates appropriate UML diagrams from the Python code. An optional type parameter even checks whether all of the parameters accepted by the Python script are consistent and properly documented for later users. Pylint also produces a variety of statistics that list the number of duplicate rows, for example.

Programmers can use plugins to extend the functionality of the tool. On request Pylint uses multiple CPU cores at the same time, speeding up the process, especially for large-scale source code. You can also integrate Pylint with various IDEs and text editors, such as Emacs, Vim, and Eclipse, and it can be used with continuous integration tools such as Apycot, Hudson, or Jenkins. Its development is significantly driven by Logilab, a company that offers commercial services related to Pylint.

One alternative to Pylint is Pyflakes. Although it works faster than its competitors, Pyflakes does not check programming style. Also, the tool individually inspects each script file, so it does not see the bigger picture, meaning that it discovers fewer errors.

Its competitor Bandit (Figure 7) examines Python code for typical vulnerabilities; thus, it is recommended on top of Pylint and Pyflakes. The tool, which comes from the OpenStack universe, particularly examines XML processing, network code (e.g., FTP, Telnet, HTTP, and SSL connections), problematic SQL queries, and encryption. Users can enable and disable the completed tests individually or add their own tests.

Figure 7: Bandit investigates Python code for security vulnerabilities. The tool comes from the OpenStack universe, where Python plays a supporting role.

Several tools for Python also harness other competitors for their analysis. For example, Flake8 tests Python scripts fed to it for errors with the help of Pyflakes, relying on PEP 8 for style checking and Ned Batchelder's McCabe script for generating statistics. Prospector deploys up to eight additional tools on top of Pylint and Pyflakes to check the source code and prepares output from these tools.

Shell

That just leaves the shell, for which a few helpers also exist (Table 4). Most shell interpreters support the -n command-line parameter, which is used to test the script passed in for syntax errors. The -u parameter tells the shell to stop working as soon as it discovers an undefined variable.

ShellCheck (Figure 8) reveals many more script errors, including incorrectly used quotes, problematic test queries, typical newbie mistakes, and even frequently used but sub-optimal commands. ShellCheck also checks the programming style to discover whether as many shell interpreters as possible can handle the script. On request, ShellCheck can be integrated with Vim, Emacs, Sublime, and Atom. The tool presents the results either as plain text, XML data, or in JSON format.

Figure 8: On the ShellCheck website, developers can even test their program code directly. The evaluation is carried out while typing.

If you only want to check whether your shell script will run on as many interpreters as possible, you can use checkbashisms as an alternative. The tool is part of the devscripts package in some distributions and as a separate package in others. Checkbashisms complains about all constructs that are not POSIX compliant.

Finally, bashate from the OpenStack developers performs a few style checks and checks for a few dangerous commands and discouraged commands.

Conclusions

Static code analyzers quickly identify errors that script programmers can easily overlook in the heat of battle. However, the tools are only as smart as their rules, and they usually only cover a small part of all possible problematic constructs.

The tools presented in this article do not examine program logic. In other words, they will not understand whether an online shop needs to multiply the prices in the shopping cart or just add them. Developers should thus not consider static code analyzers as a panacea, but merely as a useful building block in a comprehensive test plan.