While I understand that ~90% voters prefer *no spaces* for declare() 
<https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide-meta.md#441-fig-representative-results>
 
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 
<https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md>
 in 
6. Operators 
<https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md#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 
<https://github.com/php-fig/fig-standards/blob/master/proposed/extended-coding-style-guide.md#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 
<https://github.com/php-fig/fig-standards/pull/992> that have some 
arguments cited here.
** It was mentioned on another mailing 
<https://groups.google.com/d/msg/php-fig/vZOpga3xoLg/w7_BE7lFCQAJ> by 
*@PowerKiKi* but not was replied by anyone.

-- 
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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/php-fig/eccfd88b-64ab-4133-af68-e8c34deb0ca2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to