PSR-12 "closing brace of control structure" clarification

[alexey...@gmail.com]

Hi,

I tried running recent phpcs on my code base using --standard=PSR12 and among the obvious errors there was a less obvious one: "Blank line found at end of control structure".

This was pointing to the blank lines in if / else / elseif structures:

if ($foo) {

    doFoo();

} elseif ($bar) {

    doBar();

} else {

    doSomethingElse();

}

I checked the text of the proposed standard and it states in section 5:

• The closing brace MUST be on the next line after the body

So I have two questions

• Is phpcs correct in interpreting the standard? Should the brace before the elseif or else branch be considered "closing"?
• If it is correct, doesn't the rule go somewhat against the goal of making the code more readable?

I mean, removing the blank lines yields

if ($foo) {

    doFoo();

} elseif ($bar) {

    doBar();

} else {

    doSomethingElse();

}

The above code can also be rewritten as switch where the standard generously allows blank lines between case statements

switch (true) {

    case $foo:

        doFoo();

        break;

    case $bar:

        doBar();

        break;

    default:

        doSomethingElse()

}

but IMO this is also harder to understand.

[Woody Gilk]

The middle example, without extra blank lines, is correct.

--
Woody Gilk
https://shadowhand.me

--
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/5a7b2e01-36d2-4ad5-b2b2-1db11f4777ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alexandru Pătrănescu]

Hi Alexey,

And to answer your second question, the example with extra new lines before closing brace makes the code less readable, for me at least.

As you might think, how easy is to read a text is different from person to person and when this format was decided long time ago, multiple already written code from major frameworks or libraries were taken in consideration

What you can do is to work with the standard way and you will get use to it, I guess.

On another topic, you can avoid using `else` for an if condition to make code readable.

Or avoid `if` conditions by using polymorphism.

Regards,

Alex

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAGOJM6J0%3D82Ocovwr5EVujmSTPL_m%2BTor0p_Rbn8Tn9QKyX2QQ%40mail.gmail.com.

[alexey...@gmail.com]

Hi Alexandru,

> And to answer your second question, the example with extra new lines before closing brace makes the code less readable, for me at least.

Yeah, maybe you like your code with no blank lines whatsoever. However the standard usually allows adding blank lines, quoting section 2.3:

> Blank lines MAY be added to improve readability and to indicate related blocks of code except where explicitly forbidden.

So the question is: why am I allowed to add blank lines to indicate related blocks of code inside switch statements, but explicitly forbidden to do that inside if / elseif / else statements (and probably try / catch / finally, didn't check what phpcs has to say about these)?

The reasons not to allow blank lines after opening '{' and before last '}' I can understand easily and agree with these.

> this format was decided long time ago

I am asking about the "new" proposed PSR-12, not "long ago" PSR-2, in case you missed. The whole point of updating a standard is to address inconsistencies in its previous version, don't you agree?

воскресенье, 14 апреля 2019 г., 22:29:45 UTC+3 пользователь Alexandru Pătrănescu написал:

Hi Alexey,

And to answer your second question, the example with extra new lines before closing brace makes the code less readable, for me at least.

As you might think, how easy is to read a text is different from person to person and when this format was decided long time ago, multiple already written code from major frameworks or libraries were taken in consideration

What you can do is to work with the standard way and you will get use to it, I guess.

On another topic, you can avoid using `else` for an if condition to make code readable.

Or avoid `if` conditions by using polymorphism.

Regards,

Alex

To unsubscribe from this group and stop receiving emails from it, send an email to php...@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/5a7b2e01-36d2-4ad5-b2b2-1db11f4777ba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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...@googlegroups.com.

[Alexander Makarov]

> So the question is: why am I allowed to add blank lines to indicate related blocks of code inside switch statements, but explicitly forbidden to do that inside if / elseif / else statements (and probably try / catch / finally, didn't check what phpcs has to say about these)?

You are allowed to separate related blocks of code inside if/elseif/else:

if ($something) {

   // block1

   // block1

   // block2

   // block2

}

It seems that current version doesn't forbid placing blank lines after opening brace of the control structure so the following is allowed:

if ($something) {

    // hello

}

That, I think, is not good.

[alexey...@gmail.com]

Hi Alexander,

> You are allowed to separate related blocks of code inside if/elseif/else:

Yes, but block2 in your example MUST be stuck to unrelated elseif, if one follows. Why?..

I'd suggest relaxing this rule and only disallow blank line before the final closing brace in if / elseif / else and try / catch / finally statements. Otherwise once you have even a couple of short elseif's you end up with a pretty long statement where no blank lines are allowed.

> It seems that current version doesn't forbid placing blank lines after opening brace of the control structure so the following is allowed:

In fact phpcs complains about this if you run with PSR12 standard. However I can't find the relevant part in the standard either...

> That, I think, is not good.

Agree here.

понедельник, 15 апреля 2019 г., 16:38:07 UTC+3 пользователь Alexander Makarov написал:

[Woody Gilk]

> Otherwise once you have even a couple of short elseif's you end up with a pretty long statement where no blank lines are allowed.

This is a good example of "code smell". Reducing the usage of `else` and `elseif` greatly helps code readability.

--
Woody Gilk
https://shadowhand.me

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/d0ca55a4-ac96-42c1-9b5e-ec7b0d03bcc2%40googlegroups.com.

[Alexander Makarov]

https://github.com/php-fig/fig-standards/pull/1164

[alexey...@gmail.com]

Hi Woody,

This is a good example of "code smell". Reducing the usage of `else` and `elseif` greatly helps code readability.

That is a valid point. Consider this, though: long list of elseif branches is very common when lexing or parsing something. That code also is performance sensitive so refactoring should be done cautiously.

Here is an example from my own code:

https://github.com/sad-spirit/pg-builder/blob/master/src/sad_spirit/pg_builder/Lexer.php#L594

And to push the point a bit further, here is an example from twig's code:

https://github.com/twigphp/Twig/blob/2.x/src/Lexer.php#L295

OK, there are no blank lines in Twig's code, but elseif statements are moved below the closing brace of the previous branch to group related code together (and separate unrelated):

// operators
if (preg_match($this->regexes['operator'], $this->code, $match, null, $this->cursor)) {
    $this->pushToken(/* Token::OPERATOR_TYPE */ 8, preg_replace('/\s+/', ' ', $match[0]));
    $this->moveCursor($match[0]);
}
// names
elseif (preg_match(self::REGEX_NAME, $this->code, $match, null, $this->cursor)) {
    $this->pushToken(/* Token::NAME_TYPE */ 5, $match[0]);
    $this->moveCursor($match[0]);
}

So a couple questions:

• Will readability of the above code improve once you make it conform to PSR-12?
• Is there an easy way to reduce the number of elseif / else branches?
  

понедельник, 15 апреля 2019 г., 20:41:41 UTC+3 пользователь Woody Gilk написал:

[Alexander Makarov]

Readability won't be changed much. That is original code:

▮▮ (▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮ ▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮)) {

    ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮ ▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮ ▮ ▮▮ ▮▮▮▮▮▮▮▮▮));

    ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮);

}

▮▮▮▮▮▮ (▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮ ▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮)) {

    ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮ ▮▮ ▮▮▮▮▮▮▮▮▮);

    ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮);

}

This is PSR-12:

▮▮ (▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮ ▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮)) {

    ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮ ▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮ ▮ ▮▮ ▮▮▮▮▮▮▮▮▮));

    ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮);

} ▮▮▮▮▮▮ (▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮ ▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮)) {

    ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮ ▮▮ ▮▮▮▮▮▮▮▮▮);

    ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮);

}

As the way to improve the code, it's possible:

switch (true) {

    case preg_match(Token::REGEX_OPERATOR, $this->code, $match, null, $this->cursor):

        $this->pushToken(Token::OPERATOR_TYPE, preg_replace('/\s+/', ' ', $match[0]));

    break;

    case preg_match(self::REGEX_NAME, $this->code, $match, null, $this->cursor):

        $this->pushToken(Token::NAME_TYPE, $match[0]);

    break;

}

$this->moveCursor($match[0]);

▮▮▮▮▮▮ (▮▮▮▮) {

    ▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮::▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮ ▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮):

        ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮::▮▮▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮ ▮ ▮▮ ▮▮▮▮▮▮▮▮▮));

    ▮▮▮▮▮;

    ▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮(▮▮▮▮::▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮ ▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮▮▮▮▮):

        ▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮::▮▮▮▮▮▮▮▮▮▮ ▮▮▮▮▮▮▮▮▮);

    ▮▮▮▮▮;

}

▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮▮(▮▮▮▮▮▮▮▮▮);

[Robert Korulczyk]

> As the way to improve the code, it's possible:
>
> switch (true) {
>     case preg_match(Token::REGEX_OPERATOR, $this->code, $match, null, $this->cursor):
>         $this->pushToken(Token::OPERATOR_TYPE, preg_replace('/\s+/', ' ', $match[0]));
>     break;
>     case preg_match(self::REGEX_NAME, $this->code, $match, null, $this->cursor):
>         $this->pushToken(Token::NAME_TYPE, $match[0]);
>     break;
> }
>
> $this->moveCursor($match[0]);

This is not an improvement, you're overusing switch syntax to hide regular if with dynamic condition - it is closer to obfuscation than readability
improvement.


Regards,
Robert Korulczyk

[Alexander Makarov]

Well, maybe. It's widely used in Java so I've got used to it years ago.

[alexey...@gmail.com]

Hi Alexander,

Well, maybe. It's widely used in Java so I've got used to it years ago.

Well, I had a wrong assumption that coding standards are there to help with code readability and code understanding. Thanks for explaining in great detail that they are in fact a means to enshrine personal idiosyncrasies and state "we always do it that way, just because".

четверг, 18 апреля 2019 г., 15:54:09 UTC+3 пользователь Alexander Makarov написал:

[Alexander Makarov]

Readability-wise using same braces style as we're using for classes and methods would be beneficial for control structures i.e.

if ($foo)

{

    doFoo();

}

elseif ($bar)

{

    doBar();

}

else

{

    doSomethingElse();

}

Clear code blocks, vertically aligned braces.

You are right that this particular case is like idiosyncrasies but not personal ones. PSRs aren't created by a single person but a group. We have PSR-2 that we decided to be compatible with at the very start as stated in the meta-document.

If you have arguments 

[Ben Ramsey]

On Apr 21, 2019, at 04:51, alexey...@gmail.com wrote:

Hi Alexander,

Well, maybe. It's widely used in Java so I've got used to it years ago.

Well, I had a wrong assumption that coding standards are there to help with code readability and code understanding. Thanks for explaining in great detail that they are in fact a means to enshrine personal idiosyncrasies and state "we always do it that way, just because".

Readability is one reason. Consistency is another. IMO, consistency trumps readability. If people can’t agree on what’s readable, they should be able to agree on what’s consistent. Consistency often leads to readability as you get used to reading the code.

[Josh Bruce]

If you add line feeds, the readability result is the similar.

if ($foo){

    doFoo();

} elseif ($bar){

    doBar();

} else {

    doSomethingElse();

}

Doing this each structure becomes its own compound sentence or stanza in a poem, as opposed to reading like a run-on sentence:

if ($foo){

    doFoo();

} elseif ($bar){

    doBar();

} else {

    doSomethingElse();

}

Or from the Java-like example, like odd placement of punctuation meant more for a computer, not a human:

Hello
,
my name is Josh
.
I’m new to this conversation and group
;
so
,
I apologize in advance for any any social faux pas I commit
.
And am open to gentle assistance on that score
.

Cheers,
Josh Bruce

--
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/534A3ADC-2A7C-43A1-A6B5-22BDA54DFA69%40benramsey.com.

[Josh Bruce]

I also apologize up front for grammar and spelling mistakes. :)

Cheers,
Josh Bruce

[Mikko Rantalainen]

On Sunday, 21 April 2019 15:48:22 UTC+3, Alexander Makarov wrote:

Readability-wise using same braces style as we're using for classes and methods would be beneficial for control structures i.e.

if ($foo)

{

    doFoo();

}

elseif ($bar)

{

    doBar();

}

else

{

    doSomethingElse();

}

Clear code blocks, vertically aligned braces.

This is basically style called Allman-8 which I'd personally much prefer over current PSR style. The Allman-8 is used in many universities teaching computer programming because it's probably the most clear way to format your code. I see no reason to reduce whitespace from that style and I guess nobody is going to argue that they intentionally use hard to follow style for teaching.

The only argument against Allman-8 is that it has too much horizontal whitespace (tab or 8 space indent for everything) but that's just another code smell issue for me. If you feel that 8 space indent is making your code too much to the right, the code probably needs splitting to multiple methods/functions anyway.

If your only argument for PSR style is consistency, why not switch to Allman-8 now instead of waiting for more code to appear which will make the switchover even harder? Then you could have have both consistency and readability.

-- 

Mikko

[alexey...@gmail.com]

Hi Ben,

If people can’t agree on what’s readable, they should be able to agree on what’s consistent.

I don't agree that generally allowing whitespace to separate unrelated code and then explicitly forbidding this in some language constructs is consistent. Please prove me wrong.

воскресенье, 21 апреля 2019 г., 18:36:36 UTC+3 пользователь Ben Ramsey написал:

[Woody Gilk]

On Mon, Apr 22, 2019 at 4:48 AM <alexey...@gmail.com> wrote:
>
> Hi Ben,
>
>> If people can’t agree on what’s readable, they should be able to agree on what’s consistent.
>
>
> I don't agree that generally allowing whitespace to separate unrelated code and then explicitly forbidding this in some language constructs is consistent. Please prove me wrong.

No one has to prove anything right or wrong. PSR-2 was not created
by scientific study, it was created based on what the most common style
of PHP was at the time. Since its publication, the number of people
using that style has only grown.

From my perspective, this argument is a lot of bikeshedding. The
chance that PSR-12 will adopt a different brace style is extremely low
because the upgrade path from PSR-2 to PSR-12 should be simple and
obvious.

And for the record, I agree with Ben Ramsey:

> Consistency often leads to readability as you get used to reading the code.

I would rather work on projects that use PSR-2 (or 12) than whatever
any single individual has deemed "most readable".

[Joe T.]

i wholeheartedly agree with this style. Not only is it consistent as the PSR intends, it's readable and makes code-folding in IDEs much cleaner.

i want my team to comply with code standards, but right now PSR, Symfony, and Zend are the only "standards" supported by most PHP IDEs. i would love to implement this formatting as the rule, but inspection tools like PHPCS don't recognize this formatting.

i've contended for a long time that the rules in PSR-2 & -12 are inconsistent, which hurts readability 100% of the time. And it's not just a "personal feeling" about style and readability. Different structures call for different usages of operators, control characters, etc. That's the definition of inconsistency. When i programmed in C# many years back, Visual Studio pushed really hard on the Allman-8 style described above. It was jarring at first because i was coming from lazy PHP-land, but i got used to it and started to understand why it worked so well.

The fact that PSR-2 was based on survey results and what was "most common" at the time in my mind makes it a horrible standard. There's no rationale, no explanation why one context should be different from another... It's just "we always did it this way, so we're always going to do it this way.

Yes, bikeshedding the style isn't an appealing path to take. But the PSR does exactly that by requiring particular uses of braces, line formatting, spacing, etc. It seems to me the rules shouldn't be rigid about one set of rules, but allow for variants. You can keep the legacy formatting if you want, but allow for alternative rule sets, as long as the structures are built the same way, and the rules within a given project are consistent... If one project wants to use PSR-2's original style, cool. If you want Allman-8, awesome. Both styles work, and it shouldn't matter which one is used as long as it gives continuity to the project.

i realize this line of discussion is confrontational, but this is an important aspect of community programming, and when a limited set of people/projects get to determine the course for everyone else, it really should be fully open to discussion and persuasion. PSR-12 isn't likely to take any radical changes in its proposed formatting rules, but i contend that it isn't incompatible with allowing alternate style rules. i really hope that some of this discussion makes it to the working team, because right now PSR-12 is little more than a perpetuation of lazy & inconsistent practices to avoid pushing old projects and developers to sharpen up their code style.

-jlt

[Josh Bruce]

On Apr 22, 2019, at 6:58 AM, Joe T. <thoo...@gmail.com> wrote:

i want my team to comply with code standards, but right now PSR, Symfony, and Zend are the only "standards" supported by most PHP IDEs. i would love to implement this formatting as the rule, but inspection tools like PHPCS don't recognize this formatting.

FWIW, you can create custom rules (sniffs) for PHPCS. Hope that helps.

I just created one for my preferred method style, submitted as a PR for PSR-12: https://github.com/php-fig/fig-standards/pull/1165

Given that these are recommendations not standards in the strictest sense (governing body will slap your hands with a ruler until you change) nor laws (baked into the language - app won’t compile if not followed) then, at a macro-"you’re wrong!"-level, they don't matter. 

Having said that, if we create too many dialects for syntax and semantics, adoption and learning curve by peers might come into play mostly from pedants of the recommendations, “Why aren’t your braces like this? You have a blank line where there shouldn’t be one!” (Give this email to an English major.)

Because of my change above, I can’t say I follow PSR-12 100% anymore, I’m okay with this as I believe the rationale is sound; therefore, I don’t say I follow PSR-12 100% - https://8fold.gitbook.io/handbook/coding-standards-and-styles - just that I follow PSR-12 *except* here, here, and here. And I can create PHPCS sniffs to override or create my own; thereby, getting feedback from my IDE (Sublime Text 3 in this case).

I also think prioritizing who/what the recommendation is for would be beneficial.

For me:

1. Other developers (humans).

2. Average Citizen who doesn’t know how to code really and gets intimidated by all the punctuation, acronyms, and nested function calls.

3. IDEs to gain feedback and autocomplete (indirectly developers). 

[Ben Ramsey]

> On Apr 22, 2019, at 04:48, alexey...@gmail.com wrote:
>
> I don't agree that generally allowing whitespace to separate unrelated code and then explicitly forbidding this in some language constructs is consistent. Please prove me wrong.

By consistency, I did not mean that the style is consistent in all constructs. I meant that the developers are consistent in how they apply the style. That’s what’s important.

Coding standards ensure that all the developers working on a project write code in exactly the same style, regardless of how that style is defined. When working on teams, we might feel very strongly about where to put braces or whether we use tabs vs. spaces, but these things ultimately don’t matter, as long as the team agrees to write the code in the same style. I can continue to disagree with the style, but I can compromise because I agree that being consistent (writing the code in the same style as the rest of the team) is the most important reason to use a coding standard.

-Ben

[Joe T.]

Josh,

i was aware of custom rules for PHPCS, but haven't been able to dig deep into how they should be written. Last time i read into it, some formatting rules can't be overridden. Maybe that's changed, or maybe i misunderstood it the first time around.

i'll take another look at that and try to find some tutorials. Thanks for the response.

-jlt

[Josh Bruce]

Sure thing.

Try this response, without it I was sunk:

https://github.com/squizlabs/PHP_CodeSniffer/issues/2481

The ability to exclude a sniff is helpful. Recommend double-checking the sniff you’re excluding as it may have creep.

For mine I excluded method declaration from PSR-12. The implementation includes the check for not beginning methods with underscores, which I didn’t want to lose and put in with mine.

My phpcs.xml (maybe)

<rule ref=“PSR2”>

    <exclude name=“...”/>

</rule>

<rule ref=“8foldCS”>

Debating on bring the first bit directly into the custom standard.

Cheers,

Josh

--

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/7635d474-a437-4a6b-99cb-3a4158f05db4%40googlegroups.com.

[alexey...@gmail.com]

Hi Woody,

The chance that PSR-12 will adopt a different brace style is extremely low because the upgrade path from PSR-2 to PSR-12 should be simple and obvious.

Yes, the thread got a bit derailed with the braces positioning discussion. I opened a pull request with the minimal changes I suggest: https://github.com/php-fig/fig-standards/pull/1167

Hopefully it will be clearer.

I would rather work on projects that use PSR-2 (or 12) than whatever any single individual has deemed "most readable".

Agree here. And that's precisely why I was trying to make my code conform to the standard.

понедельник, 22 апреля 2019 г., 15:14:25 UTC+3 пользователь Woody Gilk написал: