[PSR-12] Spacing between assignment operator for declare()

[David Rodrigues]

While I understand that ~90% voters prefer no spaces for declare() as mentioned by @nicwortel*, I think that it should be re-reviewed and better argumented to voters in according with @PowerKiKi when he mentions that PSR suggests one space between operators in assignments.

Actually, the Extended Coding Style Guide in 6. Operators declares that "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). Other operators are left undefined".

In other words, the declare() makes an assignment of the value to a special key using the assignment operator ("="), so it does not comply with sixth section of PSR-12. It could causes confusion because of this inconsistency (inclusive, I got here for this reason).

This same style guide includes on end of 3. Declare Statements, Namespace, and Import Statements the following: "declare statements MUST contain no spaces and MUST be exactly declare(strict_types=1) (with an optional semi-colon terminator)". It give to us two special cases:

1. The "no spaces" declaration is against the 6. Operators assignment rule;
2. Off-topic: the "exactly declare(strict_types=1)" declaration could causes confusion when we treats another declare() types, like ticks or encoding that are supported by PHP, and where strict_types should be zero (which is allowed by PHP anyway). In other words, this rule should be applied to only "strict_types" or we should apply to all similar cases, for instance?

* It was pull requested by @PowerKiki at Github #992 that have some arguments cited here.

** It was mentioned on another mailing by @PowerKiKi but not was replied by anyone.

[Adrien Crivelli]

I obviously agree with you. But more importantly I am concerned that none of those concerns were properly addressed.

More importantly Larry Garfield made a very good point saying that the survey was biased. And I have not see that addressed properly. Let me quote him, because I feel it's important:

4.4: 
* The description here of the vote, IIRC, is rather misleading.  It wasn't a 
"do you like this", but a "do you have a really really good reason to not do 
it the way we've already written?"  That's why the votes are so dramatically 
biased in favor of the status quo: The survey specifically said to bias that 
direction.  The survey should be accurately described or omitted.  As is, it 
is misleading and false.  

I am afraid that we are making a standard that is supposed to be a long-term commitment based on very short-sighted views ("I don't want to edit my existing code, so let's standardize whatever it is that I am doing"). My pull-request was rejected with what feels a bit like "we'd rather have a half-assed spec than be late". I don't want to discard the entire survey, but I can't help feeling that it would need more discussions, and compromises, to reach a coherent and simple spec.

[Joe T.]

i'm right there with you guys. This PSR is full of inconsistencies, and insufficiently covers the full spread of language features. There are particular rules that almost form a pattern if you get really meticulous about what defines that rule, but it just seems so much simpler to say, "All curly braces should go on their own line. Period. End of rule." And so on...

Numerous complaints and concerns have been raised about this PSR in the last few months since the Review Phase was announced, and supposedly that's why it's still in Review. But there's been no additional public discussion by the members of the WG as far as i'm aware.

For all intents and purposes, my team is going to use PSR-12 as a baseline, and lay our own rules on top of it to address the inconsistent patterns, missing pieces, and oddities that don't really make sense in our view. Since our product isn't open source, we don't really need to worry much about published contributions where this standard would be a factor. It's primarily a guideline to get all of our own internal design patterns aligned with each other.

Unfortunate that this seems to be going stagnant (or worse, the feedback ends up ignored), because it was the most "rational" of the style guides i researched.

-joe t.