Exakat 1.0.5 review
The last Exakat version for November 2017 has been published. This time, it contains a good list of upgrades and fixes, and no less than three new analysis and a new report : regex validation, call parent:: first and uncommon environment variables. The reports are inventories, presenting any email, URL, SQL or $_GET index that is manipulated in the code. Inventories are always a great point, where you can ask yourself : what is this ‘cat’ index in my code? Let’s review Exakat 1.0.5 together.
With the upcoming change of version in PHP 7.2, it is time to start validating regex for both versions. Although the risk of incompatibility is low, it is always good to check on regex expression. They can’t be linted. Regex errors only fail at execution time.
Exakat 1.0.5 includes now a validation for every PRCE regex, using the current version of PHP. It reports any literal invalid regex. Dynamic regex, which are built from variables, are also simply tested: a simple string, without any wild character, is inserted in place of any variable. When this fails, the analysis considers the regex invalid.
An upgrade for this analysis is already planned: we’ll use the various available PHP versions to check the regex.
Call parent:: first
When a class extends another one, it is recommended to call the parent::__construct() as the first expression in the child constructor. This way, the parent class has priority, and will be valid, before the child finishes its own initialization, providing all needed features.
This is related to the ‘don’t use $this as argument in the constructor’ that was added last week: until the constructor is finished, the object is in an unstable state. Thus, sending it to another object or function is like sending unstable data. Within the constructor, the parent should be inited first, providing all necessary background for the child class to be build.
This may appears like a coding convention, rather than an error prone syntax. Though, knowing that parent::__construct() has to be called first thing, helps checking that the constructor is actually called, or not.
$_ENV is the $_GET of the system. This is where environment information come from, given by the sysadmin for the script to run. Usually, those are localization and credentials to access the database, production state, localization of helper binaries or SSH keys.
This analysis actually started at a way to report unusual variables, besides the classic one. For example, PATH, HOME, TMPDIR (various shapes) and USER (various shapes) are often accessed from PHP code.
However, the first environment variables hunt we ran on number of Open Source projects reported no conventions or common practices. 142 projects reported 324 variables, and 110 distinct values, including the following : LANG, HTTP_REFERER’, JAVA_HOME, ZEND_TOOL_INCLUDE_PATH, GDFONTPATH, HOSTNAME and a few of them with prefix : ELEFANT_, ZF_, DB_. We’ll keep collecting and reporting those environment variables for the next weeks, to detect any other pattern.
In the meanwhile, there seems to be a room for a standardization process in the PHP community : defining a standard to configure SYSTEM information that can be collected from configuration files or from environment variables. MYSQL_HOST, MEMCACHE_PORT, GREMLIN_USER, MONGODB_TTL would be easy to read and configure.
This is actually a call to action: should we submit that kind of idea to FIG or else?
Exakat already has some analysis that report unwanted strings, like hardcoded paths, hashes or passwords. There are also a few inventories that collect all the names of the classes, giving a broader view on the naming schemes of the code base.
We added targeted inventories : URL, email, SQL queries, that report all the literals found in the code. This way, you can easily identify any left over email (email@example.com, firstname.lastname@example.org, email@example.com, …) or URL (https://api.github.com/repos/%s/%s/tags, vfs://project/src/Foo/Bar.php, php://memory, https://secure.gravatar.com/avatar/http://v003l.xn--vctw07d.com/…).
We recommend to use those inventories on a regular and slow frequency: once a month is enough to review those and make sure that any internal API hasn’t been forgotten. Such error are often spectacular, but quick to fix.
Happy PHP code reviews
Exakat 1.0.5 is always looking for help : + Submit (first) names of community members to have them naming audits + Suggest missing PHP extensions + Recommend analysis that would help code better PHP + Coach us with your framework, so we can support it. Join us on Slack for a good talk.
All the 320+ analyzers are presented in the docs, including the classic ‘Should Use Local Class‘, which makes sur that methods always depends on the local class, or they should be functions. Download Exakat on exakat.io, upgrade it with ‘exakat.phar upgrade -u’ and like us on github: https://github.com/exakat/exakat.