PSR-12 / PER-CS v1 Support

[julienfalque]

PSR-12 just got approved. PER-CS v1 is the same in terms of rules, so all the changes must be included in both of them (@PSR12, @PER-CS1.0).

I think PHP CS Fixer already supports almost all of its rules. The missing cases I could notice are the following:

---

3. Declare Statements, Namespace, and Import Statements

The header of a PHP file may consist of a number of different blocks. If present, each of the blocks below MUST be separated by a single blank line, and MUST NOT contain a blank line. Each block MUST be in the order listed below, although blocks that are not relevant may be omitted.

• Opening <?php tag.
• File-level docblock.
• One or more declare statements.
• The namespace declaration of the file.
• One or more class-based use import statements.
• One or more function-based use import statements.
• One or more constant-based use import statements.
• The remainder of the code in the file.

ordered_imports currently sorts imports without considering their type. We should add an option to sort by type first. We should also add an option (or dedicated rule) to add a separation line between each import group.

---

• 5.1 if, elseif, else;
• 5.2 switch, case;
• 5.3 while, do while;
• 5.4 for;
• 5.5 foreach;
• 5.6 try, catch, finally;

[In control structures, ]expressions in parentheses MAY be split across multiple lines, where each subsequent line is indented at least once. When doing so, the first condition MUST be on the next line. Boolean operators between conditions MUST always be at the beginning or at the end of the line, not a mix of both.

We need to create a fixer that could force boolean operators to always be at the same position with two options like e.g.:

• position (beginning or end): choose whether the operators should be at the beginning or end of the lines;
• when (always or mixed): whether the rule should always be applied or only when a mix of positions is found.

We also need to support the multiple lines part of the rule:

• each subsequent line is indented at least once;
• the first condition must be on the next line.

---

• 8. Anonymous Classes

Anonymous Classes MUST follow the same guidelines and principles as closures in the above section.

You need to update class_definition to support adding a spacing before the parentheses in new class().

The opening brace [of an anonymous class] MAY be on the same line as the class keyword so long as the list of implements interfaces does not wrap. If the list of interfaces wraps, the brace MUST be placed on the line immediately following the last interface.

I think this is currently covered by the rule braces. Not sure if we should add a new option to it or create a new fixer.

---

TODO

• support for ordering imports by type first
• support for adding separation lines between import group
• support for removing blank lines between imports of the same group
• support for boolean operator position in control structure expression
• support for indenting multiline control structure expressions
• support for forcing first condition of multiline control structure expressions to be on next line
• support for anonymous class opening brace in case implements list wraps
• support for forcing blank line between import statement types ([OrderedImportsFixer] Ability to add blank line between groups #3582)
• support for adding a space before parentheses in new class() (ClassDefinitionFixer - PSR12 for anonymous class #5877)
• @PSR12 ruleset (Add PSR12 ruleset #4943)

[kbond]

What about this - specifically the part about spaces between class/function/const imports. It this possible currently?

[dmvdbrugge]

What about this - specifically the part about spaces between class/function/const imports. It this possible currently?

No, the newlines between different use types is not yet possible, however there is a longstanding issue (without PR) addressing it: #3582

edit: I would like to see that being resolved as well as part of this meta-issue

[dmvdbrugge]

When doing so, the first condition MUST be on the next line.

Is this part already covered somewhere?

As to your boolean operator fixer: I'd like the fixer to be able to do both, depending on config (always_front, always_back, when_mixed_front, when_mixed_back). It was not clear from your suggestion if you meant this, or just let it do only one of the bullet-points.

[julienfalque]

@kbond Indeed, I updated my post with PR ref given by @dmvdbrugge.

@dmvdbrugge Actually even the "each subsequent line is indented at least once" isn't supported currently. I updated my post to add the rules. As they both deal with whitespace, maybe we could implement them in a single fixer?

I also updated my suggestion for the boolean operator position fixer, hope it's better now :) Thanks!

[jdufresne]

From #4568, perhaps PSR-12 should be the default configuration for v3.

[ernst77]

Any update on psr-12 support?

[julienfalque]

Nope, nobody gave it a try yet.

[localheinz]

Perhaps it makes sense to create a branch that aggregates a @PSR12 rule set, so we can see where we are and what's missing?

[julienfalque]

We can create a @PSR12 ruleset indeed, even if it doesn't contain any specific rule yet. Though tracking progress regarding PSR-12 support is the exact purpose of the original post of this issue :)

[movahhedi]

If useful, Rule set @PSR12
Rules that follow PSR-12 standard.
https://cs.symfony.com/doc/ruleSets/PSR12.html

* not checked.

[VincentLanglet]

For the imports section https://www.php-fig.org/psr/psr-12/#3-declare-statements-namespace-and-import-statements

support for ordering imports by type first
support for forcing blank line between import statement types

The support for ordering imports by type first is implemented https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/master/doc/rules/import/ordered_imports.rst#imports_order so the checkbox can be checked.

And the support for forcing blank line between import statement types was recently added
https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/master/doc/rules/whitespace/blank_line_between_import_groups.rst
so it can be checked too.

But there is one missing item in this list.
The same import statement type MUST NOT contain a blank line.

use Foo

use Bar

use function foo;

should be fixed to

use Foo;
use Bar;

use function foo;

Can you add it to the list ? @julienfalque

[julienfalque]

Thanks @VincentLanglet, description updated.

[pstkweb]

I still have an issue with traits. Using @PSR12 rule set I expects :

<?php
class MyClass
{
    use SomeTrait;
    private $em;
    // ...
}

To be fixed to :

<?php
class MyClass
{
    use SomeTrait;
    
    private $em;
    // ...
}

But it does nothing. Any clue what could I do ?

Thanks 😉

[SpacePossum]

Hi,

Try configuring class_attributes_separation.
For example, with the default config:

$ php php-cs-fixer fix test.php --rules=class_attributes_separation --dry-run -vvv --diff
PHP CS Fixer 3.9.6-DEV Grand Awaiting by Fabien Potencier and Dariusz Ruminski.
PHP runtime: 7.4.24
Loaded config default from "/home/possum/work/PHP-CS-Fixer/.php-cs-fixer.dist.php".
Paths from configuration file have been overridden by paths provided as command arguments.
F                                                                                                                                                                   1 / 1 (100%)
Legend: .-no changes, F-fixed, S-skipped (cached or empty file), I-invalid file syntax (file ignored), E-error
   1) PHP-CS-Fixer/test.php (class_attributes_separation)
      ---------- begin diff ----------

--- /home/possum/work/PHP-CS-Fixer/test.php
+++ /home/possum/work/PHP-CS-Fixer/test.php
@@ -15,6 +15,7 @@
 class test
 {
     use SomeTrait;
+
     private $em;
     // ...
 }

(seems the SF set config for class_attributes_separation is a bit underwhelming for my liking TBH )

For more questions, please ask here:
https://gitter.im/PHP-CS-Fixer/Lobby

[a-menshchikov]

What about spaces around string binary operators (see https://www.php-fig.org/psr/psr-12/#62-binary-operators) like concatinaion?

[Wirone]

@a-menshchikov there's #6861 created recently after discussion #6849.

[ostrolucky]

PSR-PER standard has been published recently (2 weeks ago). It is an evolving standard which builds onto PSR-12.

Ref:
https://github.com/php-fig/per-coding-style/blob/master/spec.md
https://github.com/php-fig/per-coding-style/releases/tag/2.0.0

[github-actions]

Since this issue has not had any activity within the last 90 days, I have marked it as stale.

I will close it if no further activity occurs within the next 30 days.

[mvorisek]

@Wirone what about splitting this issue into the separate ones? I want to comment on 5.x, but the discussion here on multitopic is quite too long to be helpful.

[Wirone]

@mvorisek I agree, that's why I unpinned this issue some time ago. First of all I believe we should focus on PER-CS now, since #6707 was merged it's now possible to work on v2. I am not sure if investing time in PSR-12 is good at this point.

Anyway, if we want to continue working on this, we should create milestone with dedicated issues for each remaining task from this issue's checklist. @keradus what do you think about this idea? I could split this issue in the meantime.

[Jean85]

@Wirone keep in mind that PER-CS 1.0 is (intentionally) basically the same as PSR-12: https://groups.google.com/g/php-fig/c/bBh4Y-R5gxE

So you could split this up in sub-issues and keep them as valid, and just review them against the PER-CS 2.0 change list: https://github.com/php-fig/per-coding-style/releases/tag/2.0.0

[VincentLanglet]

[In control structures, ]expressions in parentheses MAY be split across multiple lines, where each subsequent line is indented at least once. When doing so, the first condition MUST be on the next line. Boolean operators between conditions MUST always be at the beginning or at the end of the line, not a mix of both.

We need to create a fixer that could force boolean operators to always be at the same position with two options like e.g.:

• position (beginning or end): choose whether the operators should be at the beginning or end of the lines;
• when (always or mixed): whether the rule should always be applied or only when a mix of positions is found.

TODO

• support for boolean operator position in control structure expression

Hi @Wirone, what about adding
https://github.com/PHP-CS-Fixer/PHP-CS-Fixer/blob/v3.49.0/doc/rules/operator/operator_linebreak.rst
to the PSR12 ruleset with the option only_booleans => true ?

The rule seems pretty similar to what is asked in PSR12.

Currently it's used by Symfony Ruleset and PSR12 ruleset.