Exakat 1.4.6 review
Exakat 1.4.6 is mostly made up of bug fixes. A number of edges cases were discovered last week and eradicated : they provide greater stability to the engine. So we took more time to augment the documentation, providing real code case and related PHP error messages that Exakat helps avoid. Error messages are typical execution time problems, yet they may be detected early in the code. Your logs will thank the Exakat 1.4.6 review.
PHP errors you can avoid
There are three types of PHP errors :
- The lintable errors
- The lintable-but-execution-time errors
- The execution time errors
Lintable errors
The lintable errors are the errors that php -l filename.php will find for you. Just run that command on any would-be PHP source code, and get instant feedback on the syntax checks. Since PHP 7.0, the number of issues that are reported by that command has grown a lot, from 200 to 900 with PHP 7.3 : this means that the code is better prepared for execution.
<?php
function foo(&$a) { print $a; }
foo('hello');
//PHP Fatal error: Only variables can be passed by reference in /test.php on line 6
?>
Execution errors
Execution error happens at execution time : who guessed ? Those errors happen with the code lints smoothly : in fact, a mistake was made in the handling of the data. Here, the number of argument is not sufficient : PHP will only determine it at execution, although we can understand it at reading time.
<?php
function foo(&$a, $b) { print $a; }
//Fatal error: Uncaught ArgumentCountError: Too few arguments to function foo(), 1 passed and exactly 2 expected foo(...['d']);
?>
When execution misses linting
Some errors are not reported by linting, but postponed until execution time. They may even be obvious to us. For example, this simple PHP code :
<?php
foo('hello');
function foo(&$a) { print $a; }
//PHP Fatal error: Cannot pass parameter 1 by reference
?>
If this code looked familiar, it is because it is a close cousin of the first example we showed earlier. The only difference is in the order of commands : the definition of foo() is after its usage. It is legit for PHP. Linting being done in one pass, PHP only lints what it knows. And, in this second script, foo() is not defined yet at function call time. So, this lints, but breaks at execution time.
Preventing more errors with static analysis
The illustrations above were set in one piece of code. The main source of lint/execution disagreements lies in the splitting PHP code into multiple files. Since the code is assembled at the last moment, linting postpones numerous validations as those could be solved by inclusions (mostly autoload), at execution time.
This is how linting can process a single file, while all classes but one, mentioned in the script, are defined in the rest of the code source. While, some error seems quite obvious to solve when set in the same file, they are a lot harder to spot when the application has a few hundreds of files :
<?php
class A extends B {}
class B extends A {}
?>
Exakat takes on analysis where lint stops : it takes into consideration the whole project and its code source. It reports situations that may generate more than 30 PHP Error messages. Exakat runs those extra analysis by default, and reports like Ambassador include them.
The Weekly Audits : 2018, Week #39
Exakat includes a ‘weekly’ report : this report is built with a selection of 5 analysis. 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
This week, we focus on five special analysis.
- Don’t Send $this In Constructor : Don’t use
$thisas an argument while in the __construct(). - Unused Private Properties : Unused static properties should be removed.
- Useless Unset : There are situations where trying to remove a variable is actually useless.
- Suspicious Comparison : The comparison seems to be misplaced.
- Randomly Sorted Arrays : Those literal arrays are written in several places, but their items are in various orders.
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 week with the ‘Go further’ section.
Happy PHP Code Reviews
All the 357 analyzers are presented in the docs, including the futuristic No Class In Global: : simply said, avoid defining structures in Global namespace. Use a custom namespace to avoid naming collisions. Although this mostly applies to older code sources, it is a common bug : 64% applications define things in the global namespace.
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.