The Exakat service has posted their latest "PHP Index of Coding" for August 2018. In this index, they share statistics from the projects the service has analyzed and some trends based on the results.

Every month, Exakat runs thousands of analysis on half a million lines of PHP code. This is primarily for testing purpose, a kind of torture test that checks the engine run on any kind of code. And it is very useful to ensure all situations are correctly handled.

We also extracted the following stats out of 1700+ projects, analysis by analysis. This way, any issue may be ranked from ‘wide spread’ to ‘very unusual’. In fact, ‘wide spread’ may also be understood as : ‘almost a feature’. May be we can suggest a few of them to wiki.php.net.

They include both the latest results and how they compare from the previous entries from May 2018. Analysis points include things like:

• Used Once Variables (In Scope)
• PHP Keywords As Names
• Property Used In One Method Only
• Unitialized Properties
• Should Make Ternary
• Use Named Boolean In Argument Definition
• Assigned Twice
• Locally Unused Property

...and many more. Some of the changes from May are pretty dramatic but others have stayed about the same. Check out the full post for the overview and links to more information about each of the checks.

The Exakat blog has an interesting post to their site sharing some statistics from the applications they've scanned related to commonly used coding styles. In this PHP Index of Coding (for 2018) they share a listing of practices in the order of popularity according to the results of over 1700 projects.

Not using @ is the poster child of good practices. It’s also looked upon, as an impossible goal. Did you know that the @ operator is only merely used by 50% of PHP applications ? Same for parenthesis with include (and co) : don’t use them, like 50% of the developpers. This is how the Exakat PHP Index of coding was born.

Every month, Exakat runs thousands of analysis on half a billion lines of PHP code. This is primarily for testing purpose, a kind of torture test that checks the engine runs on any kind of code. And it is very useful to ensure all situations are correctly handled.

We also extracted the following stats out of 1700+ projects, analysis by analysis. This way, any issue may be ranked from ‘wide spread’ to ‘very unusual’. In fact, ‘wide spread’ may also be understood as : ‘almost a feature’.

The results are ranked by frequency of appearance with the top five being:

• Uses Default Values
• Used Once Variables (In Scope)
• Unused Methods
• Method Could Be Private Method
• Should Use Local Class

For each item in the list there's a link to more information about the check and how much it has changed since the last time the index was generated.

In a new post to the Exakat blog they propose an interesting idea: making everything private in your PHP classes with the basic idea being that you can more easily move from a place with more control (private) to less control (protected/public).

It is a good recommendation to make everything private in a class : constants, methods, properties. With private, comes a tighter control on the element : no one from outside may use it, limiting the unwanted impact on the object. Of course, some of the class has to be accessible from the outside, or the object may only be manipulated as a token.

[...] Eventually, when the code matures, it becomes desirable to apply the above principle of encapsulation. This helps keeps the code clean and made of independent components. This is the beginning of a long hunt.

They show how the results look for an Exakat scan of a class and go through each of the results touching on class constants, methods and properties. It also catches when a class property is a "constant" and not modified - or able to be modified - by any means. The post ends with a recommendation to "update your code with your brain" based on the interpretation of the results.

On the Eakat blog they've written up a post showing you how to get the scanner up and running quickly on your system and start performing scans of the code based on their ruleset.

Exakat is a smart static analysis engine for PHP. It reviews the code fast and produces reports tailored for every needs : issues and code smell for programmers, inventories and maps for architect ; compilation and configurations lists for sys admins ; dashboards for team leaders. Including over 320 analysis and spanning versions from 5.2 to currently WIP 7.2, it helps you audit your code and keep it under control. Let’s see how to get up and running exakat in 15 mins.

The post then walks you through the installation process and defines some prerequisites you'll need before getting started. The Exakat installation is basically just grabbing a phar archive from the exakat.io server. Once it's installed they show you how to run your first scans and view the resulting output. The guide also shows you how to add additional options to the reporting and the command to update Exakat itself.

The Exakat.io blog has a post with an interesting method for preventing the execution of multiple instances of a script at once - locking execution with an external indicator (like files, semaphores and streams/sockets).

Like everything, it all started from a simple problem : how to prevent multiple PHP scripts at the same time. And turned into an odyssey of learning, full of evil traps and inglorious victories. In the end, it works, that’s the most satisfying and it possibly matters to no one except me. But "the way is the goal", as said Confucius, so, I decided to share the various findings.

Exakat runs in command line, and it uses a graph database. The database is central to the processing, and it is crucial to avoid running several scripts at the same time : they will write over each other. So, the problem is simple : preventing several instances to run at the same time, on the database. In commandline, there is no web server that may serve as common place between scripts, sharing some memory and implementing a locking system. It requires to use another common ground : the system.

He shares some of the methods he tried to help prevent the simultaneous execution of the Exakat process including:

• file locking using flock
• creating a "lock" file
• making it "crash proof"
• using semaphores
• using a socket for the lock

He describes some of the issues he found when running the tool using locking inside of a Docker container and, finally, the use of sockets and streams to place a "hold" until the script closes (also preventing issues on a crash). He ends the post talking about the "final boss" in his battle for locking support - the handing off of the socket connection to another process between parent and child. The final list in the post is a list of each method he tried, their benefits and downsides (but only in certain situations).

On the Exakat.io blog there's a post continuing on from a "dos and donts" article about programmer practices. In this new post cover some of the rules in a bit more detail from the original article.

Last week, I ran into ‘PHP Dos and Don’ts aka Programmers I Don’t Like‘ on reddit’s PHP group. It features a list of 11 points that the author hates finding in PHP code. [...] The most interesting point is that coding references are used to asses code. They may very well be automated, thanks to static analysis. I thought it was a good challenge for Exakat.

The list covers several of the rules in the list, providing a brief explanation (and a bit of how it relates back to PHP) including:

• Unnecessary casting
• Extra bracket and braces
• Lack of coding standard
• Too many nested if statements

He ends the post with a bit of detail about how the Exakat service is checking for these "failures" in it's newer "RadwellCode" report. He even gives the scores of some of the more well-known and used PHP projects including the Zend Framework (v1.12), WordPress, Composer and even Exakat itself.