There is an extra bit of information I wanted to share about this. I use PHPCS to analyse a number of PHP projects and determine what the common coding standards are in the PHP community: https://squizlabs.github.io/PHP_CodeSniffer/analysis/
I add a new metric today to check the number of blank lines at the top and bottom of control structures just to see how much variation there is. I don't have all the historical data, but the results for blank lines at the start of control structures are here: https://squizlabs.github.io/PHP_CodeSniffer/analysis/#blank-lines-at-start-of-control-structure Summary: Checked 537,792 control structures in 193 projects All 193 projects prefer no blank lines at the top The lowest percentage was 77% of control structures with no blank lines, but most are 90-100% 1.02% of all control structures used 1 blank line at the top 98.98% of all control structures used 0 blank lines at the top This obviously isn't data covering all PHP projects, but it covers most of the popular ones that are using PSR-2 and that are accepting contributions from people. These projects obviously have a rule that no blank lines should be at the top of control structures and are expecting that their coding standard enforces it. I don't think it would be wise to change the way PHP_CodeSniffer enforces blank lines at the top of control structures without a piece of PSR-2 errata making it official. Greg On Monday, 6 February 2017 09:00:41 UTC+11, Greg Sherwood wrote: > > Note that if the decision is that PSR-2 does not enforce no blank lines at > the start of control structures, it also does not enforce 0 or 1 blank > lines, and so this would be valid code under PSR-2: > > if ($foo) { > > > echo $foo; > } else { > > > > > > echo $bar; > } > > 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. > > Right now, developers who do not want this rule enforced in any way can > use a custom ruleset and exclude it pretty easily. Developers who want to > enforce a single blank line at the start would need to write a custom sniff > because none of the included coding standards have that rule. But that > custom sniff could be contributed to the PHPCS project so it is available > for everyone to use more easily. > > Greg > > > On Sunday, 5 February 2017 06:41:39 UTC+11, Ryan R. wrote: >> >> Hello, >> I'd like to propose a change to the PSR-2 rule concerning the presence of >> one (and only one) empty line after opening braces for conditional >> statements. >> >> Indeed I believe allowing (enforcing ?) a single empty line at the >> beginning of the conditional statement would enhance the readability of the >> code, especially when multiple conditional statements are nested. >> >> i.e : >> >> if ('string' === $dummy) { >> >> if ('values' === $mergedOptions['some_default']) { >> >> return substr($dummy, 0, 5); >> } >> >> return ucwords($dummy); >> } >> >> instead of >> >> if ('string' === $dummy) { >> if ('values' === $mergedOptions['some_default']) { >> return substr($dummy, 0, 5); >> } >> >> return ucwords($dummy); >> } >> > -- 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/a769d056-423a-4ca4-8ffe-3b2da5d61ff2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
