New in Symplify 3: 4 Time-saving Coding Standard Checkers

This post was updated on April 2018
Updated with ECS 4.0, Neon to YAML migration and checkers to services migration.

Coding Standard in Symplify 3 brings checkers build from practical use in PHPStorm. It can do lot of work for you, like add getters, remove trailing spaces, but has still some room for automation and improvement.
I already wrote about doc block cleaner fixer and here 4 more checkers, that saves you from monkey-typing and let you focus on algorithms.

Starting with the simple checkers and moving to those, which save you even hours of manual work.

1. Absolutely Require and Include

  Check the pull-request

You probably recognize this:

require 'vendor/autoload.php';

Why is this bad? It promotes relative paths by default, supports magic path resolving and can cause errors, because we expects existing file by default. You can easily end-up in ambiguous file paths like:

var_dump($relativeFile);
"/var/path/fileName.php"
# or
"/var//path/fileName.php"
# or
"/varpath/fileName.php"

Of course there are cases when using absolute paths is not suitable, like templates in Symfony application, but when we know the absolute path we should prefer it:

-require 'vendor/autoload.php';
+require __DIR__.'/vendor/autoload.php';

And that's what this checker does for you:

# easy-coding-standard.yml
services:
    Symplify\CodingStandard\Fixer\ControlStructure\RequireFollowedByAbsolutePathFixer: ~


2. Empty Line after declare(strict_types=1)

  Check the pull-request

The next one started as issue PHP CS Fixer in January 2016 (if not earlier). The story continues in next issue, but final fixer is not in near sight.

Why all these issues? Official fixer modifies code like this:

-<?php
+<?php declare(strict_types=1);
-
 namespace Abc;

Which is not what we want.

BlankLineAfterStrictTypesFixer fixer was needed so EasyCodingStandard could refactor open-source packages without any manual work:

When the official fixer is finished, I'd be happy to use it and recommend it. But right now you can use:

# easy-coding-standard.yml
services:
    Symplify\CodingStandard\Fixer\Strict\BlankLineAfterStrictTypesFixer: ~

Which helps official fixer to keep the space:

-<?php
+<?php declare(strict_types=1);

 namespace Abc;

3. One Way To Use Namespace Imports

  Check the pull-request

What do you think about this?

Import class is great PHPStorm feature. It sometimes does only partial imports, sometimes is unable to resolve conflict of 2 SameClass names and it still requires your time and attention to work.

If you don't care about this, your code can look like this - with 3 way to do 1 thing:

<?php

namespace SomeNamespace;

use SubNamespace\PartialNamespace;

final class SomeClass extends \SubNamespace\PartialNamespace\AnotherClass
{
    public function getResult(): \ExternalNamespace\Result
    {
        $someOtherClass = new PartialNamespace\SomeOtherClass;
        // ...
    }
}

If you do care - which is probably why you're reading this post - you'd prefer code like this:

 <?php

 namespace SomeNamespace;

-use SubNamespace\PartialNamespace;
+use SubNamespace\PartialNamespace\AnotherClass
+use ExternalNamespace\Result;
+use SubNamespace\PartialNamespace\SomeOtherClass;

-final class SomeClass extends \SubNamespace\PartialNamespace\AnotherClass
+final class SomeClass extends AnotherClass
 {
-    public function getResult(): \ExternalNamespace\Result
+    public function getResult(): Result
     {
-        $someOtherClass = new PartialNamespace\SomeOtherClass;
+        $someOtherClass = new SomeOtherClass;
         // ...
     }
 }

= 1 way to do 1 thing

(Don't worry about spacing after/before use statements and their order - your default PSR-2 set probably already handles that.)


Eager to try? Here it is:

# easy-coding-standard.yml
services:
    - Symplify\CodingStandard\Fixer\Import\ImportNamespacedNameFixer

4. Possible Unused Public Method

  Check the pull-request

If you create method to be used in your code only and available as service - no matter if open-source or closed-source - you might end-up with many public methods. Your application or packages grows, there are some refactoring going on, even few deprecations.

Same happened with Symplify. Eventually, I came across unused public methods that contained lot of unused code. A code I hade to test and maintain. There is already Sniff from Slevomat for unused private elements (great job guys!) - which inspired me to question:

Could a Sniff Spot Unused Public Methods?

Consider this checker as adviser, who helps to you to spot weak points and makes rest of your code more valuable and consistent, since it contains only what it needs.

This checkers requires EasyCodingStandard to run - it uses its "double run" feature:

It helps you to spot spots like this, this or this.

Run it Occasionally to Save Dozens of Hours of Dead Code Maintenance

I recommend it running from time to time in standalone thread, since it takes lot of performance and reports all unused public method, even those destined for public use:

# easy-coding-standard.yml
services:
    - Symplify\CodingStandard\Sniffs\DeadCode\UnusedPublicMethodSniff

To make the first run collection effective, a --clear-cache option must be added:

vendor/bin/ecs check src --clear-cache


Do You Want More?

There are over 30 standalone checkers in Symplify\CodingStandard 3.0 with more added every release.

See visual examples in README and decide for yourself, which you like and which you don't.

Thanks @carusogabriel for the diff idea in README. It's brilliant!



Happy fixing and sniffing!


  Continue Learning


Typo? Fix it, please  and join 49 people who build this website