PHP_CodeSniffer 1.2

[Bill Shupp]

It appears that phpcs 1.2 has different handling of multi-line method  
definitions.  With 1.1, the following would pass without warnings:

     public function directRequest($url,
                                   OpenID_Message $message,
                                   array $options = array())
     {
     }



In the above, everything is lined up on the left with the first  
argument, $url.  However, with 1.2, this is what I have to do to  
eliminate warnings:

     public function directRequest($url,
     OpenID_Message $message, array $options = array()) {
     ....
     }


This has the second line of arguments lined up with the "public"  
keyword, and the opening curly brace on the same line.  This looks  
like a bug - can anyone confirm?  If not, then I take issue this this  
representing the PEAR standard.

Cheers,

Bill Shupp

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Greg Sherwood-3]

On 05/11/2009, at 7:27 PM, Bill Shupp wrote:

> It appears that phpcs 1.2 has different handling of multi-line  
> method definitions.  With 1.1, the following would pass without  
> warnings:
>
>   public function directRequest($url,
>                                 OpenID_Message $message,
>                                 array $options = array())
>   {
>   }
>
> In the above, everything is lined up on the left with the first  
> argument, $url.  However, with 1.2, this is what I have to do to  
> eliminate warnings:
>
>   public function directRequest($url,
>   OpenID_Message $message, array $options = array()) {
>   ....
>   }
>
> This has the second line of arguments lined up with the "public"  
> keyword, and the opening curly brace on the same line.  This looks  
> like a bug - can anyone confirm?  If not, then I take issue this  
> this representing the PEAR standard.

PHPCS 1.2 implements the coding standard changes from: http://pear.php.net/pepr/pepr-proposal-show.php?id=538
It's in proposed status, but it will passed by the PEAR group IIRC.

According to that, the code should look like this:
public function directRequest($url,
    OpenID_Message $message, array $options = array()
) {
   ....
}

But it looks to me that PHPCS is not detecting your code as a multi-
line function declaration, so it's not complaining about it like it  
should.

I've noted it down and will fix it.

Greg



--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Christian Weiske]

Hi Bill,


The correct way is:
public function directRequest($url,
    OpenID_Message $message, array $options = array()
) {
    ....
}

see: http://pear.php.net/manual/en/standards.funcdef.php
"Split function definitions onto several lines"


Christian

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Christian Weiske]

Hi Greg,


> PHPCS 1.2 implements the coding standard changes from:
> http://pear.php.net/pepr/pepr-proposal-show.php?id=538 It's in
> proposed status, but it will passed by the PEAR group IIRC.
It has passed the group, but not set to "finished" in the database.


Christian

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Bill Shupp]

On Nov 5, 2009, at 12:53 AM, Christian Weiske wrote:

> Hi Bill,
>
>
> The correct way is:
> public function directRequest($url,
>    OpenID_Message $message, array $options = array()
> ) {
>    ....
> }
>
> see: http://pear.php.net/manual/en/standards.funcdef.php
> "Split function definitions onto several lines"

I've never noticed this, and don't like it.  I think it's much harder  
to read this way than splitting them on one argument per line.  And  
now, after I've spent lots of time getting my code to pass phpcs 1.1  
cleanly in my OpenID package, and now with the upgrade to 1.2, I'm  
left with 475 warnings or errors to deal with.

Bill

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Ken Guest]

this makes me think of the php_beautifier package.
if there were a way of getting it to accept errors & warnings from
phpcs and modify the tested code so that it does adhere to the
standards that'd be amazing.

k.

On Thu, Nov 5, 2009 at 5:29 PM, Bill Shupp <hostmaster@...> wrote:

> On Nov 5, 2009, at 12:53 AM, Christian Weiske wrote:
>
>> Hi Bill,
>>
>>
>> The correct way is:
>> public function directRequest($url,
>>   OpenID_Message $message, array $options = array()
>> ) {
>>   ....
>> }
>>
>> see: http://pear.php.net/manual/en/standards.funcdef.php
>> "Split function definitions onto several lines"
>
> I've never noticed this, and don't like it.  I think it's much harder to
> read this way than splitting them on one argument per line.  And now, after
> I've spent lots of time getting my code to pass phpcs 1.1 cleanly in my
> OpenID package, and now with the upgrade to 1.2, I'm left with 475 warnings
> or errors to deal with.
>
> Bill
>
> --
> PEAR Development Mailing List (http://pear.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--
http://blogs.linux.ie/kenguest/

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Bill Shupp]

On Nov 5, 2009, at 9:40 AM, Ken Guest wrote:

> this makes me think of the php_beautifier package.
> if there were a way of getting it to accept errors & warnings from
> phpcs and modify the tested code so that it does adhere to the
> standards that'd be amazing.
>
> k.

I used to think that, but one big problem I have with it is how it  
strips whitespace.  I intentionally use whitespace to delineate groups  
of functionality within a given code block.  And ultimately, you end  
up with code formatted different from what you intended.  I think it's  
better to adhere to coding standards, and use a guide like PHPCS to  
help detect problems.  Auto-formatting brings its own set of  
problems.  But it is useful for formatting code that is horrendously  
out of compliance, such as things you didn't write yourself but now  
are working on.

But in the case of this thread, where care was put into the formatting  
of code, and with an upgrade of the tool, I'm way out of compliance  
again.  All for a change to the CS I wasn't even aware of, let alone  
agree with.  It's quite frustrating.

Bill

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

[Greg Sherwood]

On 06/11/2009, at 4:29 AM, Bill Shupp wrote:

> On Nov 5, 2009, at 12:53 AM, Christian Weiske wrote:
>
>> Hi Bill,
>>
>>
>> The correct way is:
>> public function directRequest($url,
>>   OpenID_Message $message, array $options = array()
>> ) {
>>   ....
>> }
>>
>> see: http://pear.php.net/manual/en/standards.funcdef.php
>> "Split function definitions onto several lines"
>
> I've never noticed this, and don't like it.  I think it's much  
> harder to read this way than splitting them on one argument per  
> line.  And now, after I've spent lots of time getting my code to  
> pass phpcs 1.1 cleanly in my OpenID package, and now with the  
> upgrade to 1.2, I'm left with 475 warnings or errors to deal with.

You can still print one arg per line, which is also what I prefer and  
do in the PHP_CodeSniffer package. You just need to meet the  
indentation rules when you do it:

public function directRequest(
     $url,
     OpenID_Message $message,
     array $options = array()
) {
     echo 'hi';
}

Greg

--
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php