In his latest post Tomas Votruba shares some of his thoughts around the importance of code readability and the idea of "cognitive complexity".

Cyclomatic complexity is a static analysis measure of how difficult is code to test. Cognitive complexity tells us, how difficult code is to understand by a reader.

Today, we'll see why is the later better and how to check it in your code with a Sniff.

He references this post and this PDF as sources for more information about cognitive complexity but opts for code examples to explain some of the basic concepts. He then gets into the automation of these kinds of checks, using a custom code sniff to check the complexity of the code. He walks through the installation process of the CognitiveComplexitySniff and shares some example results from its evaluation.

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.

The SitePoint PHP blog has a quick tutorial posted helping you get your application PHP 7 ready with the help of the PhpCompatibility "sniffs" for the widely used PHP_CodeSniffer tool.

Sooner or later, there will come a time when you will need to migrate your projects to different PHP versions. How will you check if you’re compatible with a PHP version different to the one you’ve been developing on?

One possibility is always to install the version of PHP we want to migrate to, run php -l or something like PHPSA to check for syntax errors, check the PHP documentation for known issues with the migration and hope for the best. Or, we can use some available third party tools to check for PHP version compatibility in our projects.

The article then introduces the PHPCompatibility set of sniffs for PHP_CodeSniffer and installing them with a "git clone" in the right Standards directory. Also included are some basics for using PHP_CodeSniffer (like the command line options) and an example of some of the output from the compatibility check. The post wraps up with a real-life example using the PHPMailer codebase and testing it for PHP 5.6 readiness.

In a quick new post to his site Theo Tzaferis shows you how to set up PHPStorm and PHP_CodeSniffer to perform automatic inspection of your PHP code's syntax.

Some time ago I wrote an article on how to format your code automatically in PhpStorm to be conform the PSR standards. In this article I want to show you how you can enable inspections in PhpStorm which throws a warning if you have code which is not PSR, e.g.

• Whitespace at the end of line
• No newline at the end of file
• No newline between namespace and use statements
• etc…

This is pretty easy. We will use squizlabs/PHP_CodeSniffer from Github.

I’m doing this on an Ubuntu machine, but it should work the same in OS X (no idea about Windows).

He then provides the (*nix-centric) instructions on getting the two tools up and playing happily together. Fortunately PHPStorm comes with handy built-in support for PHP_CodeSniffer, basically only requiring you to install phpcs and point it to the right location. The rest is handled by the IDE when you enable the automatic evaluation.

On the Expert Developer site there's a new tutorial showing you how to get the PHP CodeSniffer tool up and working on a Windows installation. PHP CodeSniffer provides functionality to enforce standards and best practices in your application's development (providing code quality).

In this article we will focus on improving Code Quality. Very first step towards improving code quality is to maintain coding standards across developers. [...] Here we will talk about PHP CodeSniffer, which help us to maintain coding standard across multiple developer. Dealing with CodeSniffer is much easier: create rule set, validate your file against your rule set and get the result immediately. It will immediately show how many mistakes you have made in terms of following coding standards and eventually all developer will start coding as per coding standards you have defined.

There's two main parts to the article: first is getting PEAR installed (a package manager for PHP) and then using it to install CodeSniffer. Complete instructions and commands are included as well as a few screenshots along the way.

The Zumba Engineering blog has a new post looking at a way you can control code quality and standards with the help of Composer, git hooks and the PHP Code Sniffer (phpcs) tools.

Maintaining code quality on projects where there are many developers contributing is a tough assignment. How many times have you tried to contribute to an open-source project only to find the maintainer rejecting your pull request on the grounds of some invisible coding standard? [...] Luckily there are tools that can assist maintainers. In this post, I’ll be going over how to use composer, git hooks, and phpcs to enforce code quality rules.

These three technologies are combined together to make a more seamless experience for the developer while keeping the code quality high. Their method makes use of the "scripts" (post-install-cmd) feature of Composer to, after the installation of all packages, set up a git hook script that will run the phpcs checks on pre-commit. It's a pretty simple shell script that kicks back any errors it might find before the user can commit their changes.

In his latest post Pádraic Brady shares some of his thoughts around coding standards and the existence of tools to be sure the code is exactly formatted correctly.

The problem with coding standards is not the notion of following conventions to ensure all programmer can quickly read and understand code (and other good stuff), but that someone created a tool to actually check compliance: PHP_CodeSniffer. This isn’t a complaint about the operation of phpcs, but to complain about the mere fact of its existence. [...] Using the cover of such automated tools, we can make judgement calls about code quality, integrate style checks into Continuous Integration scoring schemes, complain about pull requests and patches, and generally impose a time penalty on writing code. There is a point at which common sense morphs into sheer nitpicking, and an automated tool is the perfect nitpicker.

In his opinion, coding standards should be "invisible and flexible" as well as easy to learn so the developers could learn and follow it quickly. He looks at these thoughts applied to the PSR standards and how adhering to them could quickly turn into something much more time consuming than it should. In his opinion a good coding standard is one that "limits the rules, eradicates ambiguity, formulates multiple use cases and avoids trivialities".

In a new post to his site Phil Sturgeon talks about the "success story" around the PSR-2 PHP-FIG standard and his work to get the PHP CodeSniffer checks to be more correct for it.

I've had static analysis tools running in Sublime Text for a long time, but for most of that time I have had CodeSniffer and it's PSR-2 rules disabled. I couldn't for the life of me remember why I had done that, until I turned it back on again. All of a sudden it started complaining about code that I had always considered to be perfectly compliant. It reminded me of multiple conversations I've had with others in the FIG and the community in general, about how CodeSniffer often enforces rules in the PSR-2 spec that do not exist, or were not what was meant when it was written. Two months ago I set off on a mission, to get CodeSniffer in line with what PSR-2 really is.

He gets into a bit of the backstory around the checks and the addition of "Errata" to add to the specs that have already been defined. The goal isn't to alter what's been defined, but to help clarify some issues (or close some loopholes) that might have come up. After polling the PHP-FIG mailing list about it - and it passing unanimously - the Errata was added and the CodeSniffer rules were updated to match (PHP_CodeSniffer 1.4.7).

If you're interested in other unclear places in the PSR-2 spec and want to discuss it, check out this gist and the conversation that goes with it.

In a new post to his site Christian Weiske shares an update he contributed to the PHP_CodeSniffer functionality to make working with and checking the validity of local PHP code easier - a notifier for PHP_CodeSniffer using the "notify-send" commonly installed in most Linux distributions.

I use emacs as IDE, and wanted to have direct feedback about the validity of my .php files when writing them. The most easy way was to add a save hook that runs PHP_CodeSniffer - but the results should be displayed in a nice, unobtrusive way. phpcs has multiple reporting modes - xml, checkstyle, csv etc. - but nothing for the desktop. I thought that notify-send would be the right fit since it is able to display pretty popup messages without getting in the way.

He also includes the details on his original objective - including it in a "on save" hook as well as providing it in a keystroke shortcut, making checking his code even easier.

Klaus Silveira has created a set of PHP_CodeSniffer rules that can be used to test your code for the recently approved PSR-1 & PSR-2 standards.

This is a PHP_CodeSniffer sniff to check against the PHP Standard Resolutions: PSR-0, PSR-1 and PSR-2. Those standards were approved by the PHP Framework Interoperability Group. You can read more about the PHP FIG and the PSR's on this excellent article by Paul Jones.

The github repository also provides an overview of the standards themselves and how to get these sniffs installed.