Exakat 1.6.5 Review

The Exakat 1.6.5 review comes in with a lot of extensions and some new analysis. In particular, we add support for pcov and weakref, two interesting PECL extensions; New analysis report variables that are used as conditions, and arrays that are initialized as strings (duh!); Finally, the Ambassador report and several previous analyses were extended, covering even more situations than before. To the Exakat 1.6.5 review, and beyond!

weakref and pcov

Wearef is both a PECL extension and a current RFC. This extension is authored by Joe Watkins. The goal of the weak references is to allow the PHP engine to unset those references, in case it needs to free memory. This means that an object may disappear during execution.

This is useful for caching strategies : instead of accumulating cache during the life of the application, some objects are marked for priority unsetting. Weak references would be available, alongside the traditional references.

Pcov is ‘a self contained CodeCoverage compatible driver for PHP7′. It works with PHPUnit, and provide the much-needed information about code line execution and control flows. PHPunit uses them to establish the Code Coverage of a test suite.

Both extensions are now reported by Exakat. It is recommended to prevent pcov to reach production, while weakref should not be forgotten.

No Variable Is A Condition

This analysis spots variables that are used as raw conditions. Here is an example below :

    
<?php

if ($error) {  
   echo, 'Error : '.$error;
}

?>

In this situation, it is easy to read that the condition on the $error variable is actually a test on its content. When no error was spotted, then $error is probably empty, and thus, the application skips the display. When the error is explicit, then, the variable is filled with a non-false value, and this leads to the display.

In environment where warnings are hidden, the mere existence of the variable may be tested with way too.

Generally speaking, it is recommended making the condition explicit. Here, we could have an explicit comparison with the empty string, or, if the variable maybe undefined, a call to isset().

    
<?php

if (isset($error)) {  
   echo 'Error : '.$error;
}

?>

If $error is always set, then a comparison with an explicit value carries more meaning than a auto-cast comparison to false. For example:

    
<?php

if ($error !== '') {  
   echo 'Error : '.$error;
}

// same as above, with a constants const NO_ERROR = '';
if ($error !== NO_ERROR) {  
   echo 'Error : '.$error;
}

?>

The last line is even better : the code is fully readable, with the constant name acting as a readable and executable comment. It even has the added value to be updateable with other values, without changing the code.

As a general rule, it is recommended avoiding variables as conditions, even when it should only contain a boolean : make the comparison explicit, and maintainable.

PHP 7.1 doesn’t transtype from string to array

Until PHP 7.1, it was possible to initialize a variable with an empty string, and later, use it as an array. PHP would transtype the value immediately in an array. See it in action on 3v4l.org.

    
<?php

$a = '';
$a[3] = 4; var_dump($a);
// PHP 7.0 and older :  
// string(4) "   4"

// PHP 7.1 and more recent /*
array(1) {   
[3]=>
  int(4) 
}
*/

?>

Although it is not very clever to initialize a variable with a string and use it as an array, this was an old habit that took a good old in many developers’ code : the most versatile way to initialize a variable and forget about it is to use an empty string. This skips the ‘Undefined variable’ error, and yet, provides for both arrays and strings.

PHP 7.1 has moved to skip the silent type-cast. In particular, it emits non-fatal errors with string index, (‘Illegal string offset’) but set 0 in the array.

Exakat now reports variables that are initialized as strings, but used as arrays, in the compatibility report for PHP 7.1.

The Weekly Audits : 2019, Week #07

Exakat includes a ‘weekly’ report : this report is built with a selection of five analyses. This means a short audit report, with few issues to review. This is not a lot to read them, and review them in your code. Everyone in the PHP community can focus on one of the classic coding problems and fix it. Talk about the weekly audit around you : you’ll find programmers facing the same challenges.

To obtain the ‘weekly’ audit, run an audit, and request the ‘Weekly’ report.

# Init the project (skip when it is already done)    
php exakat.phar init -p <yourproject> -R https://github.com/Seldaek/monolog.git -git 

# Run the project (skip when it is already done)    
php exakat.phar project -p <yourproject> 

# Export the weekly project (every monday)    
php exakat.phar report -p <yourproject> -format Weekly 

# Open projects/<yourproject>/weekly/index.html in your browser    

Every week, you can find here 5 new analysis to review in your code. In fact, when your code is clean, you can also take a quick look at the upcoming

Weekly recommendations for PHP code review : 2018, week 2019-06

• Timestamp Difference : time() and microtime() shouldn’t be used to calculate duration.
• Parent First : When calling parent constructor, always put it first in the __constructmethod.
• Too Many Local Variables : Too many local variables were found in the methods.
• Could Use DIR : Use DIR constant to access the current file’s parent directory.

Happy PHP Code Reviews

All the 354 analyzers are presented in the docs, including the smart : Mismatch Type And Default: this is when argument typehint and the default value of an argument don’t match.

It is a rare bug (3%), but it definitely bruises some ego when it emerges.

You can check all of the Exakat reports at the gallery: exakat gallery.

Download Exakat on exakat.io, install it with Docker, upgrade it with ‘exakat.phar upgrade -u’ and like us on github.