Re: Questions about enforcing new CS in PHP_CS

On 24/11/2008, at 5:56 PM, Christian Weiske wrote:

Hello Greg,

** Split function definitions onto several lines ** A couple of other options are also valid under the new standard: public static function getInstalledStandards( $includeGeneric = false, $standardsDir = '' ) { public static function getInstalledStandards( $includeGeneric = false, $standardsDir = '' ) { Do you have anything against developers using those methods? Also just a note that there are 3 different ways developers can write their code, all with varying degrees of readability. Do you want strict enforcement to one of these methods or should each developer choose their own?

All three methods are legal. It depends on the situation which way is best, and it's the developer's task to choose the right one. I know that this brings ambiguity, but I trust the PEAR developers to do the right thing.

** Split function call on several lines ** Easy question; is this valid or is only one object operator allowed per line if you are using multiple lines: $someObject->someFunction("some", "parameter")->someOtherFunc(23, 42) ->andAThirdFunction();

It is valid to have several object operators on one line.

And what happens in the unlikely scenario where you are multi-line function calls mixed in; you get this (valid by the standard): $someObject->someFunction( "some", "parameter", "and", "another long parameter", array(true) )->someOtherFunc(

       23, 42

)->andAThirdFunction(); Two problems with the above; multi-line function calls inside concatenated function calls look wrong and using multiline function calls when you don't need to looks wrong. Do you want any additional checks for this sort of code?

No, I don't think additional checks are not needed. In my opinion, people will not strive for such code but sometimes it is just necessary - and for this case, we set some general rules.

Thanks for the clarification.

** Alignment of function parameters ** Do you want any checking for this standard? I assume it is not a requirement that you indent in this way (MAY be aligned, not MUST be aligned).

It is optional, yes. PHPCS could give out brownie points if people align parameters, though :)

** Alignment of assignments ** PHPCS currently throws warnings when you don't align. Considering the standard has changed to "the equal signs MAY be aligned", do you want any enforcement, or was the intention just to stop warnings when it requires excessive indentation?

The intention was for one to stop warnings like "is indented 4 spaces, requires 39" - and warnings when you e.g. create an object and then assign object values. Alignment in this case does mostly make no sense:

$var = new Object(); $var->a = $bar; $var->foo = $blase;

While I like the alignment of the property assignments, I hate to align the object instantiation. So since there is no hard length limit, we decided to drop the requirement and make alignment optional. You could give out brownie points when people align with in 1 and 10 characters ("Exceptionally beautiful code").

Well, PHPCS doesn't give positive scores, so I'll just remove the sniff completely and no longer check alignment of equal signs. I'm sure that will make more than a few developers happy :)

** Array formatting ** Are any of these standards to be enforced? The language of the standard suggests these array formatting standards are optional.

They should be enforced in a way that arrays are either aligned or not aligned at all, using minimal whitespace:

array( 'foo' => bar', 'foobär' => 'irgendwas', 'ohmy' => 'god', )

or

array(

   'foo'    => bar',

'foobär' => 'irgendwas', 'ohmy' => 'god', )

not:

array(

   'foo'    => bar',

'foobär' => 'irgendwas', 'ohmy' => 'god', )

So either one space is valid after the key, or the number of spaces that align it correctly? Doesn't this go against the equal sign alignment where it is completely optional and there is no check at all? And if there is a check, does it too need the max number of indentation spaces like the equal sign recommendation has? Greg