PSR2: Multiline conditionals

[Pittiplatsch]

As already stated in #454 (comment), code like this:

if (
    true
    || false
) {
    1;
}

is valid for PSR2 and should therefore not throw errors like Expected 0 spaces after opening bracket; newline found.

[edited link to issue]

[jian-wu]

Looks like I'm not alone - #459. 😄

[Pittiplatsch]

Ups, yes. However I believe that CS should not throw an error for a rule which actually is not broken.
Even if current behaviour is caused by the fixer, this doesn't justify throwing non-existant errors IMO.

[jian-wu]

Agreed. I've requested it to be a warning at the most.

[gsherwood]

is valid for PSR2 and should therefore not throw errors

What makes you think this code is valid in PSR-2? The example code looks pretty clear and states Note the placement of parentheses, spaces, and braces: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md#51-if-elseif-else

[Pittiplatsch]

As already stated by several people all over the web, PSR2 does not make clear assumptions on each and every statement on how to format them when it comes to excessing single line length.

After all, PSR2 longs for good readability, and it's obvious for me to utilize the same rules that are explicitly given for other use cases, e.g. for method calls:
https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md#46-method-and-function-calls

PSR2 states definitive rules of where to place spaces (IMO in terms of ASCII 32) to unify overall styling of braces, i.e. encourage if ($foo over if($foo, if ( $foo, if($foo and the like.

However, I don't think that PSR2's term "space" is to be understood as regex-ish \w (i.e. ANY whitespace).

Don't want to argue too much, but IMO when even PSR's people don't make it to achieve some agreement for all the years the problem exists (see https://github.com/php-fig/fig-standards/issues?q=is%3Aissue+condition) than any tool aiming to follow PSR2 should not make any additional assumptions, as this obviously will throw errors not coverd by PSR2, and moreover will lead to discussions like this one.
What if I want to use two competing code style tools at the same time, but they make contrary assumptions on vague rules like that one?

Btw.: Even ZF2 will fail with many errors once they upgrade to CS2.2 - because there simply is no clear rule...

[gsherwood]

any tool aiming to follow PSR2 should not make any additional assumptions

I'm specifically trying to not make assumptions. I will ask on the PHP-FIG-CS mailing list and see if someone can clear this one up.

[gsherwood]

I will ask on the PHP-FIG-CS mailing list and see if someone can clear this one up.

Actually, it seems like @pmjones has already indicated that there should not be a newline.

Firstly here: https://github.com/php-fig/fig-standards/issues/181
Then much more recently here: https://github.com/php-fig/fig-standards/issues/261

I'll still ask on the mailing list for a bit more clarification.

[Pittiplatsch]

Hope you're luckier than all the guys before...
By now, all I found were prevarications, suggesting to refactor code like this to completely avoid these situations...

[Pittiplatsch]

Actually, it seems like @pmjones has already indicated that there should not be a newline.

I saw those ones too, actually I had these posts in mind when I wrote my last comment.
However, I can't see any reliable hint to the one or the other direction. On the contrary:

This comes up so often that we should add it to the meta document.
https://github.com/php-fig/fig-standards/issues/181#issuecomment-24595159

So, thx for your efforts to gather more concrete information. :-)

[jian-wu]

Honestly, I really don't like creating explaining variables. That to me is no different than breaking up multi-conditional if statement into nested single if statements.

Anyway, 👍 for trying to getting more concrete answer to this issue.

Thanks a bunch.

[gsherwood]

I've posted here: https://groups.google.com/forum/#!topic/php-fig-cs/9yc7Go8dJkM

Personally, I think that treating the word "space" to mean a literal space character makes things much easier, so I'm interested to see what other people think on that mailing list.

I'd be very happy to make this change, although I do think it would be a lot better to have a really clear multi-line control structure format defined in the standard. But I know this will never happen because PHP-FIG have already stated that PSRs are never changed once released.

[jian-wu]

Well, they can always release PSR-5. 😄

Thanks and good luck to us all.

[gsherwood]

It's been over a month and I've had zero replies to my post. Because of this, I'll leave PHPCS as it is based on the previous php-fig issues I linked to.

If anyone has more success getting something concrete documented, please reopen this issue (or just open a new one) so we can discuss it again.