[PSR-12] Operators MUST be preceded and followed by at least one space

[Greg Sherwood]

Hi,

I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question about this section:

6. Operators
All binary and ternary (but not unary) operators MUST be preceded and followed by at least one space. This includes all arithmetic, comparison, assignment, bitwise, logical (excluding ! which is unary), string concatenation, type operators, trait operators (insteadof and as), and the single pipe operator (e.g. ExceptionType1 | ExceptionType2 $e).

I think it is pretty clear that operators can be surrounded by however many spaces and newlines that the developer wants, and I've coded a check to enforce this, but it seems like it would lead to inconsistent code. So I just wanted to check and make sure the following code snippet should be considered valid under PSR-12:

<?php
if ($a     === $b) {
    $foo = $bar     ??     $a   ??   $b;
} elseif ($a        >  $b) {
    $variable = $foo  ? 'foo'      : 'bar';
}

I'm obviously exaggerating the spacing, but the main thing I'm getting at is that it seems like code can have different padding on either side of an operator, and different padding can be used throughout the file, as long as some form of padding is used (at least 1 space). This seems to go against what a coding standard is trying to achieve, which is a level of consistency throughout the source code of a project.

If this is not the intention, I'd suggest standardising on a rule that says that operators must be surrounded by exactly 1 space OR a newline. If a newline is being used, no further checks are performed i.e., the developer can use as many spaces as they want for indentation as long as they remain inside the rest of PSR_12's rules.

Thanks

[Joe T.]

Agreed! When does more than one space (aside from newlines) ever make sense? i hope these details get resolved...

-jlt

[Daniel Hunsaker]

Multiple spaces before (or, less often, after) an operator can be useful when attempting to align operands.

<?php
$short           = 'foo';

$somethingLonger = 'bar';

There are other cases, but that's one of the most common.

--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/6ea3c2e7-2f2b-4c86-9535-8b10319b40e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Greg Sherwood]

On Monday, 23 April 2018 14:00:11 UTC+10, Daniel Hunsaker wrote:

Multiple spaces before (or, less often, after) an operator can be useful when attempting to align operands.

<?php
$short           = 'foo';

$somethingLonger = 'bar';

There are other cases, but that's one of the most common.

Yes, I do this myself, which is why I normally check assignment operators separately from others. But PSR-12 specifically defines one rule for all operators, so I have to apply the same rule to comparison operators (for example) that I do for assignment operators.

[Daniel Hunsaker]

I often find it helpful to align operators other than assignment operators, too. Comparison, bitwise, Boolean, arithmetic, and so on, are equally subject to operand alignment to improve readability. Which is why I said "operator" instead of "assignment operator", though my quick example only included the one type.

--

You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/c21a1db6-b7ac-4b8a-8a5c-0cd2b4e3eaed%40googlegroups.com.

[Woody Gilk]

On Sun, Apr 22, 2018 at 10:59 PM, Daniel Hunsaker <danhu...@gmail.com> wrote:
> Multiple spaces before (or, less often, after) an operator can be useful
> when attempting to align operands.
>
> <?php
> $short           = 'foo';
> $somethingLonger = 'bar';

The problem with this is when you have a number of aligned variables,
and then add a longer one (or remove the longest), it forces a much
bigger change in the source diff than what is really being changed.
Yes, you can often use "ignore whitespace" during review, but code

(and "blame" history) has been modified as a result of whitespace.

--
Woody Gilk
http://about.me/shadowhand

[Greg Sherwood]

On Monday, 23 April 2018 14:16:40 UTC+10, Daniel Hunsaker wrote:

I often find it helpful to align operators other than assignment operators, too. Comparison, bitwise, Boolean, arithmetic, and so on, are equally subject to operand alignment to improve readability. Which is why I said "operator" instead of "assignment operator", though my quick example only included the one type.

Point taken, but I'm really more focused on the sort of code I posted originally. Leaving a rule completely open is fine, but I want to make sure that is the intention given it will absolutely lead to messy code (created by accident) not being detected by a static analysis tool.

Once I release PSR-12 inside PHPCS, I now receive *all* bug reports when people don't agree with how it works, and I have to justify a standard I didn't write. It happened with PSR-2 (hence errata) and I found it much easier to deal with if I've already asked the questions and can point people to an answer by the authors.

[Alexander Makarov]

Yes, it was intentionally left open for alignment purpose.

[Larry Garfield]

On Sunday, April 22, 2018 11:30:06 PM CDT Greg Sherwood wrote:

> Point taken, but I'm really more focused on the sort of code I posted
> originally. Leaving a rule completely open is fine, but I want to make sure
> that is the intention given it will absolutely lead to messy code (created
> by accident) not being detected by a static analysis tool.
>
> Once I release PSR-12 inside PHPCS, I now receive *all* bug reports when
> people don't agree with how it works, and I have to justify a standard I
> didn't write. It happened with PSR-2 (hence errata) and I found it much
> easier to deal with if I've already asked the questions and can point
> people to an answer by the authors.

Greg, THANK YOU for taking the time to file these reports. This sort of
feedback is exactly what the "2 implementations" rule is for before an
Acceptance Vote can be called, so that these sorts of questions can be caught.

Please do keep them coming!

--Larry Garfield

[Greg Sherwood]

On Tuesday, 24 April 2018 06:03:04 UTC+10, Alexander Makarov wrote:

Yes, it was intentionally left open for alignment purpose.

Sorry, I missed this reply. Thanks for clarifying.

Greg