Re: [PSR-12] Closure guidelines for anon classes

ng brace MUST > go on the next line following the body. > > > On Tuesday, April 24, 2018 at 1:53:06 AM UTC+3, Greg Sherwood wrote: >> >> Hi, >> >> I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question >> about this section: >>

Re: PSR-12: closing brace MUST NOT be followed by any comment

While I disagree with this specific part of the standard, having it in there at least means a decision has been made and code will be more consistent for it. Coding standards should be opinionated, and I think PSR-12 needs more rules and not less. Greg On Wednesday, 16 May 2018 18:08:50 UTC+10

Re: [PSR-12] Operators MUST be preceded and followed by at least one space

On Tuesday, 24 April 2018 06:03:04 UTC+10, Alexander Makarov wrote: > > Yes, it was intentionally left open for alignment purpose. > > Sorry, I missed this reply. Thanks for clarifying. Greg -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperab

[PSR-12] Closure guidelines for anon classes

Hi, I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question about this section: 8. Anonymous Classes > Anonymous Classes MUST follow the same guidelines and principles as > closures in the above section. Almost the entire closure section of PSR-12 is dedicated to argument li

Re: [PSR-12] Spacing for INSTEADOF and AS in trait trait use blocks

Yeah, it could. But when PSR-12 says to "take note of spacing" what is it referring to then? Does it just mean the indent? Does it mean spacing around the comma, or around the braces? The examples with "take note" style comments are used throughout PSR-2 and again in PSR-12, but it makes it qui

Re: [PSR-12] Blank line after trait use import statement

permitted. Extra blank lines feel like something >> wasn't finished. It's just... ew. >> -jlt >> >> >> On Sunday, 22 April 2018 19:52:02 UTC-4, Greg Sherwood wrote: >>> >>> Hi, >>> >>> I wrote the PSR-1 and PSR-2 standards for PHP_Co

[PSR-12] How to deal with comments inside trait use blocks

Hi, I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question about comments in general. PSR-2 explicitly excluded comments so I ended up writing a lot of checks that just treat comments like whitespace. PSR-12 doesn't look like it does this, but it hardly mentions comments, so

Re: [PSR-12] Operators MUST be preceded and followed by at least one space

On Monday, 23 April 2018 14:16:40 UTC+10, Daniel Hunsaker wrote: > > I often find it helpful to align operators other than assignment > operators, too. Comparison, bitwise, Boolean, arithmetic, and so on, are > equally subject to operand alignment to improve readability. Which is why I > said "o

Re: [PSR-12] Operators MUST be preceded and followed by at least one space

On Monday, 23 April 2018 14:00:11 UTC+10, Daniel Hunsaker wrote: > > Multiple spaces before (or, less often, after) an operator can be useful > when attempting to align operands. > > $short = 'foo'; > > $somethingLonger = 'bar'; > > > There are other cases, but that's one of the most co

[PSR-12] Operators MUST be preceded and followed by at least one space

Hi, I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question about this section: 6. Operators > 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 (exc

[PSR-12] Spacing for INSTEADOF and AS in trait trait use blocks

Hi, I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question about this section at the bottom of 4.2: When using the insteadof and as operators they must be used as follows > taking note of indentation, spacing and new lines. > > class Talker > { > use A, B, C { >

[PSR-12] Blank line after trait use import statement

Hi, I wrote the PSR-1 and PSR-2 standards for PHP_CodeSniffer and I'm now writing a PSR-12 standard as well. I have a question about this section: 4.2 Using traits > ... > When the class has nothing after the use import statement, the class > closing brace MUST be on the next line after the use

Re: Enhance code readability

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-fi

Re: Enhance code readability

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:

Re: Enhance code readability

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