I agree that this could be organized to be easier to understand at a glance, but I don't understand why this is still an issue. It sounds like PHPCS is assuming that code needs to exactly match examples in every way. That's simply not the case. I've shown that the document says specifically that blank lines are allowed for readability, can anyone show anything in the document that says differently?
What I would do is take this to PHPCS. I don't think this deserves errata, instead we should take care with PSR-12 to make sure that this misunderstanding doesn't continue. Best wishes, Korvin On Mon, Feb 6, 2017 at 6:15 PM Greg Sherwood <gsherw...@gmail.com> wrote: > On Monday, 6 February 2017 20:45:47 UTC+11, Ryan R. wrote: > > I use an extreme example here to show how relaxing coding standards can > lead to unexpected results and thus inconsistency. It seems to me that > developers relying on PHPCS to keep their code clean through checking and > auto-fixing will now have to use custom rulesets to enforce what is a > pretty standard rule. That feels like a big step backwards. > > > @Greg : Would it not be possible to add some kind of parameter value to > indicate the upper limits authorized ? And set it to 1 by default (or 0 > since you do not want to modify the current system because of the number of > projects relying on it) ? > Then if we want to allow empty lines we could simply modify the parameter > value ! > > > Yes, that's what I was trying to suggest in my reply. Either way, some set > of developers would not be able to use the included PSR2 standard as-is - > they would need to use a ruleset.xml file and either include a specific > sniff or change a sniff option. > > Given that developers who want to allow a single blank line already have > to use a custom ruleset, keeping the default at 0 blank lines means those > developers can change their ruleset from excluding the sniff to changing > one of its settings - making it more useful. > > But obviously, the side effect is that you're not following PSR2 as PHPCS > sees it. I don't think this makes any difference (any consistency is good) > but maybe others do. > > If you think an option would solve your specific problem and you're not > too concerned about if PSR-2 in PHPCS enforces 0 or 1 blank lines, then I'd > suggest opening a new Github issue and we can work out a solution along > those lines. > > Greg > > -- > 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/10a99a91-547e-4cc9-b05f-d58f2b6ef7b4%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/10a99a91-547e-4cc9-b05f-d58f2b6ef7b4%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/CANeXGWVXauPbbRkeJnaOc%2BQT5X%2BJbUYn5_Wyn1ZN37K6MSYyMg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
