unary_operator_spaces included in PSR-12 and PER-CS

[nsrosenqvist]

Bug report

Description

The rule unary_operator_spaces rule is included in the rulesets PSR-12 and PER-CS, and it also removes spaces between the not operator and proceeding statement. From what I can understand, reading the specs, the not operator has no enforced rule regarding it. The spec says this regarding operators:

When space is permitted around an operator, multiple spaces MAY be used for readability purposes.

All operators not described here are left undefined.

And only mentions rules for increment/decrement and type casting when it comes to unary operators. So from my understanding this means that this shouldn't affect the not operator. Am I understanding it correctly? Is there a way to override that specific behavior if one should wish so?

Runtime version

PHP CS Fixer 3.40.0 (45a4530) I ate three cookies 🍪 by Fabien Potencier and Dariusz Ruminski.
PHP runtime: 8.3.0

Code snippet that reproduces the problem

<?php
-  $var = ! $negate;
+ $var = !$negate;

[Wirone]

It was already reported in #7388 (where the rule was added to the PSR-12 ruleset), and discussed in #7303 - please look at this comment. I am going to close this is as this is not a bug, but expected behavior. If you feel that unary_operator_spaces shouldn't be part of PSR-12 or at least it should be configurable, please create "Feature idea" discussion 🙂.

[wimski]

@Wirone

I am going to close this is as this is not a bug, but expected behavior.

Where in this section does it follow that it should be expected behavior to have a space removed from anything other than increment/decrement or type casting operators?

https://www.php-fig.org/psr/psr-12/#61-unary-operators

You guys keep insisting that PSR-12 says that this space rule applies to all unary operators, even-though the documentation never states this.

My other comment pointing out this fact was always conveniently ignored.

[nsrosenqvist]

Please @wimski, @Wirone never dismissed the idea that it could be made configurable. They suggested that one could make a feature discussion around it which could lead to its implementation. No need to assume any bad intent.

[wimski]

@nsrosenqvist

Let me start by saying I always assume good intentions and I'm thankful for all the effort that goes into any package 😘

The frustration one might have tasted in my earlier comments, stems from the fact that I strongly disagree with the opinion that removing spaces surrounding ALL unary operators should be the expected behavior when dealing with the default PSR-12 ruleset.

Can someone explain to me why it should be expected behavior - and subsequently where my reasoning is flawed - if the following is true:

• The PSR-12 ruleset fixes code styling according to the official definition.
• The official definition of PSR-12 explicitly states:

  • The increment/decrement operators MUST NOT have any space between the operator and operand.

  • Type casting operators MUST NOT have any space within the parentheses:

• The official definition of PSR-12 doesn't mention anything else, especially nothing specific regarding other situations concerning unary operators and spaces.

From this it would follow, that one should expect that a statement like ! $var for example should not be changed.

[Wirone]

@wimski you had discussion with @keradus who provided his perspective on the matter, and I just act with that in mind 🙂. @keradus is the project's leader, I only follow directions. Maybe I was not clear enough, I meant the current behaviour is expected in terms of @keradus' approach, because it was him who added unary_operator_spaces to the ruleset and then provided the reasoning after initial complaints. That's why I said it's not a bug, because it was already discussed and works in a way it was designed (if it's correct is totally different story). If you feel this should be changed, then please open the discussion (preferably in RFC section) and try to convince him to change his mind 😉. If it was only for me, I could agree with you, but I am not decisive here.

[wimski]

@Wirone thanks for taking the time to respond.

[...] works in a way it was designed (if it's correct is totally different story)

Then my assumption of thinking those two things should be the same were clearly the flaw in my reasoning 🙈

If it was only for me, I could agree with you, but I am not decisive here.

Good to know I'm not completely mad 😉

I'll plan that discussion then to argue (in general) that a PSR-12 ruleset should follow the PSR-12 definition.