Matt Glaman has written up a post for his site showing how you can write better Drupal code using PHPStan, the PHP static analysis tool.

PHP is a loosely typed interpreted language. That means we cannot compile our scripts and find possible execution errors without doing explicit inspections of our code. It also means we need to rely on conditional type checking or using phpDoc comments to tell other devs or IDE what kind of value to expect. Really there is no way to assess the quality of the code or discover possible bugs without thorough test coverage and regular review.

If you use PhpStorm, you will notice all of their helpers which analyze your code and add static analysis. [...] That's awesome. It's pretty amazing that PhpStorm and a few plugins can give us some stability in our PHP code.

While the functionality in PhpStorm is useful, there are some pitfalls including the fact that everyone would have to use PhpStorm. He makes the suggestion that PHPStan can effectively replace these helpers and, with a bit of customization, provide just as much quality control for your Drupal code. He links over to a custom PHPStan extension for Drupal and an example YAML configuration. He also includes helpful tips around bootstrapping the autoloader, return typing and changes it provides for using the entity manager.

The PHP Roundtable podcast, hosted by PHP community member Sammy Powers, has posted their latest episode: #73 - PHP Static Analysis. In this episode Sammy is joined by Ond?ej Mirtes, Craig Duncan, Vladimir Reznichenko and Damien Seguy.

Static analysis is a fancy word to describe a tool that looks at our code and gives us helpful hints on how to improve it. We'll be discussing what static analyzers do, which tools the PHP community has access to, and how we can incorporate the tools into our daily development flow.

You can catch this latest episode in a few different ways: either using the in-page audio or video player, by downloading the audio file directly or by watching the recording over on Youtube. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

Tomas Vortuba has a new post to his site sharing some of his experiences with static function analysis (and fixing) and the trap he got himself into when evaluating the current state of his code. This is a continuation of his series covering the use of the SymfonyCodingStandard package.

PHP story with code examples, copy-cat killers, just a little bit of static, consistency, sniffs and way to prevent all that ever happening ever again.

In his post he uses an example "fixer" for testing DocBlock comments to see if they provide much useful information over what the PHP itself provides. He dives "under the surface" and looks at the steps it takes to accomplish this. He then gets to the "trap" part, showing the code behind the fixer and how depending on 3rd party packages and their parsing lead to code mistakenly being "fixed". He finishes up the post with a look at a few solutions that could help make these "traps" easier to fix including dependency injection and preventing the issue specifically with static functions.

Jakub Zalas has a new post to his site sharing a Docker image he's created to help make static analysis for your PHP code simpler: the phpqa image.

As part of my job I often perform application reviews and code quality analysis for clients who wish to have their code base looked at by an independent company. Running static analysis tools is usually a starting point to the review as it gives a general overview of a state of the project. I also like to run those tools as part of an introduction to an inherited code base.

For an easy access to the most popular static analysis tools for PHP I recently created a docker image - phpqa.

He lists out the tools that are included with the current version (a quite lengthy list) including:

• analyze
• box
• deptrac
• php-code-fixer
• phpDocumentor
• phpa
• phploc
• phpmd
• phpstan
• psalm

...and many more. Check out the full post for more of the tools in the list and links to more information about each one.

On the SitePoint PHP blog they've posted a new tutorial showing you how to analyze tweet sentiments using a combination of PHP and machine learning (with the help of the php-ai/php-ml library).

As of late, it seems everyone and their proverbial grandma is talking about Machine Learning. [...] Yes, what about Machine Learning and PHP? Fortunately, someone was crazy enough not only to ask that question, but to also develop a generic machine learning library that we can use in our next project. In this post we are going take a look at PHP-ML – a machine learning library for PHP – and we’ll write a sentiment analysis class that we can later reuse for our own chat or tweet bot.

The post then starts in with some of the basics of machine learning and sentiment analysis and briefly introduces the php-ml library and what functionality it offers. It then outlines the problem they're trying to solve and the solution including what data points php-ml will use to determine the sentiment of a tweet. The author shows how to get the php-ml package installed, how to read in the data set and how to "exercise" the sentiment analysis against the tweets. It describes how the evaluation works and shows the accuracy result of a basic run.

In this post over on Medium.com Ond?ej Mirtes looks at what he calls the "Three Pillars of Static Analysis in PHP" - three kinds of testing you can do to catch errors "at rest" in your codebase.

My credo is that everything that can be automated should be automated. Computers are really good at repeating tedious tasks and they don’t usually make mistakes while us squishy humans are defined by making mistakes everywhere we go.

[...] In the following article, I’d like to introduce three tools that will help you to find errors and inconsistencies in your codebase. If your build integrating these tools finishes successfully, you can be pretty sure your application is in a good shape.

His list of three tools covers checking for:

• syntax errors using PHP-Parallel-Lint
• PHP_CodeSniffer "sniffs" to ensure code consistency
• using PHPStan to check for more complex bugs and issues than the other two

He covers some of the things the last option verifies and links to another introductory article about the tool to help you get started.

In this post on Medium.com Ond?ej Mirtes introduces a tool that can be use to statically analyze your PHP application and locate bugs without the need for tests - PHPStan.

Keeping up with modern PHP practices leads to codebases where we can be sure about types of a lot of data, converging with statically typed languages, although the dynamic nature is still present. Modern PHP codebases are similar to the ones in languages people make much less fun of. Object-oriented code, dependency injection and usage of established design patterns are truly common nowadays.

Which led me to the idea of a static analysis tool for PHP that would substitute the role of the compiler from other languages. I’ve spent a lot of time working on it and I’ve been employing its various development versions checking our codebase for more than a year.

It’s called PHPStan, it’s open-source and free to use.

The post goes on to talk about some of the checks that PHPStan performs (with more information available in the project's README). He also talks about the performance of the tool, how to extend it and configuring it for "strictness". He ends the post by pointing out that, despite the title of the article, he still encourages writing tests, just making sure they're "meaningful ones" that test more than just syntax.

The Master Zend Framework site has posted a new tutorial for those making the move in their legacy applications up to the world of PHP 7. In it Matthew Setter shows how to use phan, a static analysis tool, to locate issues that could cause breakage in the upgrade.

Unless you’ve been living under a rock these last 12 - 18 months, you will have heard about PHP 7; the latest version of PHP. Not only is it fast, by some reports it’s up to twice as fast as PHP 5.6, and far less memory hungry.

[...] Unfortunately, your application’s source code may not be 100% compatible with version 7. Upgrading may well leave you with a broken application and a set of unhappy customers. So before you go breaking your site in the interests of speed and being one of the cool kids, find out if your code’s compatible. How? By using a static code analyser, one which gives you all the changes you need to make on your code, so that you can upgrade with confidence.

He then shows how to install the Phan tool via Composer and execute it against your codebase. The result of his commands are a file that contains the issues found during the scan. If there are some "false positives" you'd like to ignore he also shows you how to create a config.php file with these and other values set to make it all more reusable.

On the SitePoint PHP blog there's a post from Claudio Ribeiro introducing you to a new static analysis tool to help improve the quality of your code - PHP Static Analyzer, or "PHPSA" for short.

One requirement that never changes whether you are working on your projects alone or in a team, on small projects or big, is Code Quality. The bigger the project and the team, the harder it gets to maintain it.

A good way of slowing this increase in difficulty down is to use static analysis tools. Static analysis is the process of analyzing software without actually executing the program – a sort of automatic code review. Static analysis tools will detect common errors, enforce coding standards, and even clean up code blocks. The days of php -l filename are not over, but we now have a number of great tools that go the extra mile in helping us create and maintain high quality code.

They start with an example of using the tried and true "php -l" to lint an example PHP file but note that the yes/no answer it provides doesn't help give much feedback on the quality of the code, just its syntax. Enter PHPSA, a Composer-installable tool that does much more than lint checking. It also provides information about things like missing docblocks, function alias use and undefined property usage. they show an example of it in use on the command line, the results it provides and the changes made to the example class to fix the issues it found.

On the Viva64.com site they've posted the results of their own evaluation of PHP 7 in terms of both the source of the language itself and the libraries it makes use of.

Sometimes checking a project one more time can be quite amusing. It helps to see which errors were fixed, and which ones got into the code since the time it was last checked. My colleague has already written an article about PHP analysis. As there was a new version released, I decided to check the source code of the interpreter once again, and I wasn't disappointed - the project had a lot of interesting fragments to look at.

They start with a brief look at PHP 7 including when it was released, some of the features/functionality included and the tool they used to do the analysis. They talk about some of the difficulties in the analysis process and how the widespread user of macros tripped it up a bit. They includes some code examples from PHP's source and the warnings that their PVS-Studio returned. The post ends with a brief look at the third-party libraries PHP uses and the responsibility the project takes in including them.