Company

Exakat 1.8.5 Review

Posted on by dams

Exakat 1.8.5 Review

Exakat 1.8.4 and 5 are maintenance version, that focus on fixing edge cases and speeding up analysis. In particular, several analyses have taken advantage of the constant resolution system, to apply checks on literal and constants alike. We also included a new analysis that checks if literal could be replaced by an existing constant. And the Ambassador report now includes the configuration file of the current audit, to configure another repository. I can’t change the Exakat 1.8.5 review, but I can adjust my code to always reach my destination.

Constant resolutions

The Exakat engine keeps track of constants, and their definition. It covers classic constants, with define() or const, but also class constants. This means that the actual value of a constant, when defined in the code, is used wherever the constant is used.

<?php

const MY_FORMAT = "[%s]\n";

printf(MY_FORMAT, $s, $t); // Too many parameters provided

?>

While constants are a formidable tool to federate literals, and have a central point to update them, they also tend to hide the actual value behind a name. This is the case above, where MY_FORMAT is not telling about the actual format, but about the author of the format. As such, resolving the constant, and finding its actual literal value help find bugs that are not obvious.

Note that Exakat also resovles static constant expressions, so if MY_FORMAT is a concatenation, and still statically resolvable, the engine will resolve the constant correctly.

Literal Could Be Constant

With the idea to promote more constant usage, as seen above, a new ‘Suggestions’ has been added : it reports Literal Values that could be replaced by an actual constant.

<?php

const MY_CONSTANT = "abc";

$a = 'abc';

?>

Here, $a is initialized with ‘abc’, while there is already a constant which holds this value. If this applies, it is recommended using the constant for the initialization. Later, it will help update the value from ‘abc’ to another value, without proof-reading the whole application.

Special values like true, false, 0, and 1 are ignored. While they may very well end up being constant, for the same reasons as above, they are usually too often used, and yields a huge amount of false positive. Or real issues, which are all interlaced. This doesn’t help.

As a suggestion, it is worth avoiding those special values, and use other literals for simple comparisons. This usually helps creating lists of special values, and then, pave the way to replacing them by constants.

Could Use Trait

Could Use Trait is a close cousin to Could Use Interface : it detects a class, which has the same methods as a specific trait, yet doesn’t use that trait. Look at this academic example :

<?php

trait t {
    function foo($a) { return ++$a;}
    function foo1($a) {return ++$a;}
}
class x {
    function foo($a) { return ++$a;}
    function foo1($b) {return ++$b;}
    function bar() {}
    function bar1() {}
}

?>

In the example above, foo and foo1 are defined in the x class. They are also defined in the t trait, and they are actually identical. This way, class x could be simplified, and make use of use t;.

Exakat has a clone type 1 representation of each method, and use them to compare the methods between the trait and the class. A clone type 1 is a clone based on tokens : the tokens are the same in both methods, and in the same order. Yet, the value of the token may differ. For example, note that foo1 in class x uses a $b as argument, while it is a $a in trait t.

In another analysis, Exakat reports interfaces that may be used to characterise a class, but which has not been added with the implements keyword.

Export Used Configuration

The Ambassador report includes a new item in the Annex section : the Audit Configuration presents the configuration used to create the current audit. They are in INI and YAML format, which are the two formats used by Exakat.

You can copy/paste those configuration in your config.ini or .exakat.yaml files, in another repository. This is convenient to spread the same configuration across multiple code repositories, in the same company.

The Weekly Audits: 2019, Week #26

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 analysis.

Weekly recommendations for PHP code review : 2019, week 2019-24

Happy PHP Code Reviews 

All the 360 analyzers are presented in the docs, including the hideous :
: Multiple Type Variable: avoid using the same variable with different types of data. It makes it difficult to keep track with the value itself.

This is a common source of bug in source code (43%).

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.