PHP CodeSniffer: Ignoring rules

PHP CodeSniffer is a great tool for making sure all your code is consistent with a set of rules and guidelines. However, there are cases, when you need to ignore the rules for a particular code snippet. For example, when you are working with third-party frameworks or libraries.

CodeSniffer provides a number of ways to do this. Until today, the following worked well for me:

// @CodingStandardsIgnoreStart
echo "Here goes some code that breaks the rules";
// @CodingStandardsIgnoreEnd

This is particularly useful for code within functions and methods. But what if you need to ignore a particular rule for the whole file, especially in places like method names, which are difficult to surround by starting and ending annotation tags?

Here’s an example that worked for me (thanks to this comment for the solution):

<?php
/**
 * @phpcs:disable CakePHP.NamingConventions.ValidFunctionName.PublicWithUnderscore
 */

The only bit that you’d probably need now is an easy way to find the name of the rule from the CodeSniffer output. The usual output of “./vendor/bin/phpcs” looks like so:

FILE: src/Model/Table/KeysTable.php
-----------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------------
 53 | ERROR | Public method name "KeysTable::_initializeSchema" must not be prefixed with underscore
-----------------------------------------------------------------------------------------------------

But if you run it with the “-s” flag (thanks to this comment), CodeSniffer will add sniff codes to all reports. Here’s the same example with “./vendor/bin/phpcs -s“:

FILE: src/Model/Table/KeysTable.php
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 1 ERROR AFFECTING 1 LINE
------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 53 | ERROR | Public method name "KeysTable::_initializeSchema" must not be prefixed with underscore
    |       | (CakePHP.NamingConventions.ValidFunctionName.PublicWithUnderscore)
------------------------------------------------------------------------------------------------------------------------------------------------------------------------

And that’s the code sniff rule that you can add to the ignore annotation tag at the top of your file, like I’ve shown above.

Git tips: disable diff prefix

Pure gold.

GitHub adds PHP and Composer dependency graphs

Here are some great news from GitHub: Dependency graph support is now available for PHP repositories with Composer dependencies.

You may see security alerts on your repositories as dependency graph support rolls out. When there’s a published vulnerability on any of the Composer dependencies that your project lists in composer.json and composer.lock files, GitHub will send you an alert including email or web notifications, depending on your preferences.

These now work for both public and private repositories, and repository admins can enable or disable the features as needed.

Google: How to do a code review

Google is sharing “How to do a code review” as part of its engineering practices. Unlike many similar guides online, I find this document to be a lot more comprehensive. It covers both the technical bits of the process, as well as suggestions that improve overall team communications and efficiency.

A particular type of complexity is over-engineering, where developers have made the code more generic than it needs to be, or added functionality that isn’t presently needed by the system. Reviewers should be especially vigilant about over-engineering. Encourage developers to solve the problem they know needs to be solved now, not the problem that the developer speculates mightneed to be solved in the future. The future problem should be solved once it arrives and you can see its actual shape and requirements in the physical universe.

Perl 6 re-branding

Curtis “Ovid” Poe, the author of the book “Beginning Perl” and long-time Perl Monk, has this excellent post on the re-branding discussion of Perl 6.

Even though I’m not writing much Perl code these days, I have to admit that the whole Perl 6 thing has been going for years now and I’m one of those many people who were confused by it. In my opinion, Perl 6 is not a continuation of Perl 5 as a version bump (like in Python or PHP), but it is a different language. And as a different language, it should have a different name.

Of the ones mentioned in the blog post, I like the “Raku” the best. But given the negative connotation in some countries, cultures, and languages, “Camelia” seems like a better option.

Regardless of the alternative names, I want the change from “Perl 6” to anything else the sooner, the better.