Static code analyzers for JavaScript, PHP, Python, and the Linux shell

Script Doctor

© Lead Image © Ewa Walicka,

© Lead Image © Ewa Walicka,

Article from Issue 188/2016

Admins daily use scripts to automate tasks, generate web content, collect and parse data, and perform many other tasks. A few sophisticated tools can tell admins where script problems lurk.

Administrators are likely to throw together a shell script quickly during the stress of everyday admin life, but sometimes it takes only a few days before the script self-destructs. Meticulous, time-consuming, and typically hectic troubleshooting commences. Thank goodness for static code analyzers.

Code analyzers examine source code for errors and typical problems, such as typos that a human is likely to overlook – from uninitialized variables to incorrectly used semicolons. Predefined test rules decide whether an error exists, and programmers can specify their own test criteria in some cases.

These code analyzers are referred to as "static" because they only see the source code; they cannot make any guesses about future performance. Some tools that perform data flow analysis and track variables through the program code can find unused or unnecessary variables.

For dynamically typed languages, such as Python, the variable type is only defined at run time, so the analysis tools need to guess what data could eventually reside in what variables. The result is that they sometimes mark as an error what is actually correct (false positive).


Many static code analyzers evaluate bad programming practices and thus act as style checkers as well. The analysis is based on commonly accepted coding style guides (e.g., the PEP 8 [1] standard, in the case of Python). Some tools generate statistics and make suggestions for improvements. For example, if the analyzer detects many identical rows, it can advise the developer to outsource them into a separate function.

Most static code analyzers are command-line programs, so the developer can include them in (shell) scripts or their own toolchain. Only a few tools include a front end, which usually just shows the output of the command-line version. Ideally, the tools integrate text editors and IDEs, so the programmer sees coding errors when entering the code.

Lint, which was one of the first static code analyzers, took a close look at C programs, and its name prompted the similar naming of other tools. For example, Pylint takes cares of Python programs. Apart from the names and goals, these "linters" have nothing in common.


JavaScript has several linters (Table 1), such as JSLint by Douglas Crockford (Figure 1). The tool is written in JavaScript, and you can try it out directly on the home page; the source code is on GitHub [2]. JSLint checks the style of programming in addition to syntax and reveals some structural problems.

Table 1

JavaScript Static Code Analyzers




Closure Tools

Apache 2.0






MIT Expat and JSON


Modified MIT (open source, non-free)






Apache 2.0

Figure 1: Enter the JavaScript code in the large text box on the JSLint website and press the JSLint button to run a check.

The tool takes a more restrictive approach, in that it enforces version 6 of the ECMAScript standard, which means a semicolon at the end of each statement and no allowance for the == operator. JSLint is released under a modified MIT license. Users can use the tool only for good, but not for "evil purposes." The Free Software Foundation classifies the license as non-free.

The alternative JSHint, like JSLint, checks syntax, complains about bad programming style, and reveals typical problems, such an implicit type conversion. JSHint in the current version supports ECMAScript 3, 5.1, and 6. You can try JSHint directly at the project homepage (Figure 2). Developers can integrate JSHint into their own web pages as a JavaScript module.

Figure 2: JSHint is an alternative to JSLint, which also runs in a browser. The software detects bad programming style and implicit type conversions.

A command-line version of JSHint requires Node.js. JSHint feels at home in many text editors, such as Vim, Emacs, Sublime, Atom, and Brackets. The tool is released under the JSON license, which has provisions similar to the license used with JSLint.

ESLint is released under a plain vanilla MIT license. In contrast to JSLint and JSHint, the ESLint tool packs each check rule into a separate plugin that the programmer can enable and disable as required – even at run time. Users can contribute their own plugins, as well. The supplied rules cover syntax errors, check for best practices (e.g., the use of eval()), complain about overly complex constructs, and point out bad programming style.

The tool supports ECMAScript 6; however, users need to enable support for the standard explicitly. You can test ESLint directly on the website [3]; a command-line version is also available that requires Node.js.

Google provides various tools for JavaScript programmers as closure tools, including the Closure Compiler (Figure 3). Closure Compiler converts JavaScript statements into "compact, high performance" code and also performs syntax checks and variable type checks, warning you about common problems.

Figure 3: The Closure Compiler removes all unnecessary characters from source code and corrects it at the same time: Here, it has removed and added semicolons.

Closure Compiler is available online on Appspot [4], and it runs locally as a Java program in a command-line version or via the REST API. It supports ECMAScript 3, 5, and parts of version 6. As a supplement, Google provides the Closure Linter, which investigates programming style [5] according to the Google JavaScript style guide [6] and calls foul in case of missing semicolons, among other problems.

Flow, developed by Facebook, primarily focuses on data flow and examines variable content and type. It complains, for example, if a function tries to compute something the programmer has assigned to a string. That said, Flow only checks JavaScript files that the developer has identified with an appropriate comment. What's more, you need to add annotations to the variables to state their desired types.

Using the appropriate plugins, you can integrate the tool with Vim, Emacs, and Nuclide. Moreover, you can run a Flow server in the background and incrementally re-investigate JavaScript files as they are changed. The tool itself is written in OCaml.

The development of JSPrime has already been on ice for two years; however, the tool explicitly checks JavaScript code for some security vulnerabilities. Additionally, JSPrime can handle minified Java code. You control JSPrime via a web client.

Many other tools available on the Internet simply leverage other applications. For example, TAJS relies on the Closure Compiler, whereas Plato puts the JSHint and ESLint team to work.


PHP developers can also rely on various helpers (Table 2). PHP checks the source code itself for syntax errors by calling a .phpfile with the -l parameter set.

Table 2

Static Code Analyzers for PHP














PHPLint [7] goes beyond this capability, handling both PHP5 and PHP7 applications (Figure 4). In addition to searching for syntax errors, PHPLint also starts data flow analysis, ensures that exceptions are correctly handled, verifies function signatures, and ensures consistent types.

Figure 4: You can try out PHPLint directly in the browser: Drop PHP code into the input field and then run the parser by pressing the button bottom at right.

Developers can help PHPLint by adding comments to the code that explicitly state the variable types. As a bonus, the tool will generate documentation on request directly from the source code. PHPLint is written in PHP and requires the PHP CLI command-line interpreter; some distributions put the command-line interpreter in a separate package.

PHP mess detector (PHPMD; Figure 5) positions itself as an alternative to PHPLint. The mess detector is based on the JMD static code analyzer for Java [8]. PHPMD searches the source code for errors, suboptimal code, unnecessarily complicated expressions, and unused parameters or methods. PHPMD outputs the results either in text, HTML, or XML format. Although the tool has been around since 2009, the developers still consider it a young project and apologize for the sparse number of rules supplied.

Figure 5: Developers need to tell PHPMD the file to be examined, the output format, and the desired rule set. Here PHPMD checks variable names.

Phan, another contender programmed entirely in PHP7, really is quite young. Among other things, Phan tests whether source code will run in PHP7. In its analysis, Phan also considers PHPDOC comments, such as @depricated or @param, as well as generics, namespaces, traits, and variadic functions.

RIPS was popular for many years. Unlike the other tools, RIPS is a web application written in PHP. The PHP programmer uses a form to pass in the script you wish to test, and RIPS then outputs a variety of facts with a colorful layout (Figure 6). In particular, it looks for vulnerabilities, including SQL injections, cross-site scripting, and code execution.

Figure 6: RIPS is a web application written in PHP; above all, it identifies vulnerabilities.

The founder of RIPS stopped developing the tool in 2013, and only a few bug fixes have been incorporated in the past few years. Originally, a completely new version 1.0 was supposed to be developed, but there are no signs of it materializing. Because RIPS is not familiar with current attack techniques and cannot handle modern versions of PHP, you can only use it for an initial assessment.

Strictly speaking, PHP_CodeSniffer does not belong to the group of static code analyzers. The tool checks to see whether the source follows one or multiple coding standards. Among others, the PEAR standards, PSR-1, and PSR-2 are available. PHP_CodeSniffer also tests for a few typical sources of error, such as functions not properly declared. The tool returns the results either as a simple text message or in another format, such as XML, CSV, or JSON. Users can even define test settings in php.ini. For example, a call to

phpcs -d include_path=.:/php/includes test.php

would add the /php/includes directory to the include path when checking the test.php file. PHP_CodeSniffer can process PHP7 applications and, as a bonus, can even parse JavaScript code, with some restrictions.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

comments powered by Disqus