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 On Sun, Apr 14, 2019 at 9:54 PM Woody Gilk <woody.g...@gmail.com> wrote: > The middle example, without extra blank lines, is correct. > -- > Woody Gilk > https://shadowhand.me > > > On Sun, Apr 14, 2019 at 12:07 PM <alexey.bor...@gmail.com> wrote: > >> 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. >> >> -- >> 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+unsubscr...@googlegroups.com. >> To post to this group, send email to php-fig@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 >> <https://groups.google.com/d/msgid/php-fig/5a7b2e01-36d2-4ad5-b2b2-1db11f4777ba%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> 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-fig+unsubscr...@googlegroups.com. > To post to this group, send email to php-fig@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/CAGOJM6J0%3D82Ocovwr5EVujmSTPL_m%2BTor0p_Rbn8Tn9QKyX2QQ%40mail.gmail.com > <https://groups.google.com/d/msgid/php-fig/CAGOJM6J0%3D82Ocovwr5EVujmSTPL_m%2BTor0p_Rbn8Tn9QKyX2QQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > 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-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAAwdEzC%2BdYABZmJA%3DOr4Qb5HFPhsXy_E9Semq7VDi9nzo_Vd3w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
