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.

Following up on his prior post showing how to convert DocBlock comments to official type hinting, Tomas Votruba has continued the series with a new post showing how to do the same thing but without previously defined DocBlocks.

In previous post we looked at how to migrate from docblocks to type declarations. From @param Type $param to Type $param. Even if it doesn't break code like coding standards do, works with inheritance, localized self and static and propagates types to all child classes, it's still not such a big deal.

But how do you complete type declarations if don't have any docblocks?

After a "gloom and doom" start to the post, he circles back around and shows how PHPStan and Reactor can help with static analysis. After providing several examples of how the refactor should look, he shows how to set up Reactor for both return types and the migration of properties to their correctly typed versions automatically.

Tomas Votruba has a post to his site showing you how to combine EasyCodingStandard and PHPStan on a Symfony-based ecommerce project. This is the second part of a series comparing the code of three popular Symfony ecommerce packages (part one is here).

In the last post, we looked at the static analysis of 3 Symfony E-Commerce projects.

Lines of code, Duplicated code, Cyclomatic complexity or Method length. These metrics are very rarely used in practise (even though there is a sniff for that).

Today, I am going to show you how you can check them with tools that can help you keep your code better on daily basis - EasyCodingStandard and PHPStan.

He's provided the code he used to analyze the packages - ShopSys, Sylius and Spryker. He goes on to talk about some of the tool choices and the resulting code violations from the PSR-2 checks. He also covers some of the "cleaners" that helped to remove some dead code and the violations uncovered by PHPStan.

In this new post to his site David Négrier talks about "type hinting all the things" in response to a recent controversy around "clean code" and "visual debt" in PHP code.

Recently, a video about "visual debt" as sparked a lot of controversy in the PHP world. In this article, I'll present the best practices we are using at TheCodingMachine, and a brand new tool we use to enforce those best practices.

If you haven’t seen the video yet, you can have a look at it on Laracast. At some point, the video advocates to remove the type-hints because they are not needed by the program and are "visually polluting" the code.

He then breaks down his look at type hinting and the benefits they can provide into a few sections:

• Type-hints are good
• Type-hints have improved (… but there is still a long road to go)
• Enforcing type-hints

He also covers some of their own best practices when it comes to type hinting in their code and shares a phpstan package that they use to enforce typing and formatting based on their own standards.

Ondrej Mirtes has offered some advice in this Medium.com post sharing some of his experience in the development and management of his PHPStan project (static analysis for bug detection).

Most developers have side projects. That's how we try out new things or make something that we miss on the market or in our dev stack. But most side projects end up unfinished and never actually see the light of day. And even if a developer builds up the courage to show his work to the public, he quickly finds out that just publishing a repository doesn't actually bring the masses to his doorstep.

At the beginning of last December, I released PHPStan? - ?static analysis tool for PHP that focuses on finding bugs. The project gained a lot of traction resulting in currently over 1 300 stars on GitHub and more than 30 000 downloads on Packagist.

He spends the rest of the article sharing the things he did to make sure that the project "didn't end up in the dustbin of history" and be successful. Topics include:

• Build the hard stuff first
• Serve market needs
• Promotion
• Ask for money

He ends with what he sees as the most important part of any good open source project - as a maintainer you need to "be nice". This means being responsive to incoming feedback, keeping in mind that people contribute/comment because they care about the project (and it's not usually about you).

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.