[PEPr] Proposal for RFC::Coding standard enhancements

[Christian Weiske-2]

Christian Weiske (http://pear.php.net/user/cweiske) proposes RFC::Coding standard enhancements.

You can find more detailed information here:
 http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Chuck Burgess-2]

Chuck Burgess (http://pear.php.net/user/ashnazg) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

These all look good to me.  In particular are the changes to mitigate the
effects of the 85-char line width CS rule.  In my CS cleanup work in
PhpDocumentor, this line width rule alongside all the current spacing rules
has proven the hardest to repair.  The proposed changes will greatly ease
this.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Philippe Jausions-2]

Philippe Jausions (http://pear.php.net/user/jausions) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

Good to update the CS for these oft-encountered long lines.



My comments by section:



 - "Split function definitions onto several lines". Not a big fan of ) {
on the same line. I'd rather see the ) on the same line as the last
parameter, and leave the { on its own line.



 - "Split long if statements onto several lines". For better readability
expressions in parentheses should be indented by 1 for each grouping. i.e.
(Note: I'm not sure how that'll look on the comment once posted though)



if (($condition1

      || $condition2) <-- indent 6 spaces here

     && ($condition3 <-- indent 5 spaces here

           && $condition4) <-- indent 9 spaces here

    ) { <-- indent 4 spaces here (?)

     //code here

 }

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Jonathan Street]

Jonathan Street (http://pear.php.net/user/streety) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

I think the alignment of assignments is perhaps overly strict.
Particularly in comparison to the alignment of function parameters.  So to
compare,



"To support readability, parameters in subsequent calls to the same
function/method **may** be aligned by parameter name:"



with



"To support readability, the equal signs **should** be aligned in
block-related assignments:"



Emphasis is mine.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Philippe Jausions]

Philippe Jausions wrote:

> Philippe Jausions (http://pear.php.net/user/jausions) has commented on the proposal for RFC::Coding standard enhancements.
>
> Comment:
>
>  - "Split long if statements onto several lines". For better readability
> expressions in parentheses should be indented by 1 for each grouping. i.e.
> (Note: I'm not sure how that'll look on the comment once posted though)
>
> if (($condition1
>       || $condition2) <-- indent 6 spaces here
>      && ($condition3 <-- indent 5 spaces here
>            && $condition4) <-- indent 9 spaces here
>     ) { <-- indent 4 spaces here (?)
>      //code here
>  }

My count was wrong, but you get the idea

if (($condition1
     || $condition2) <-- indent 5
    && ($condition3 <-- indent 4
        || $condition4) <-- indent 8
   ) { <-- indent 3 to align with "(" or 0 (?)
    // code here <-- indent 4
}

>
> Proposal information:
> http://pear.php.net/pepr/pepr-proposal-show.php?id=538
>


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

[David Jean Louis-2]

David Jean Louis (http://pear.php.net/user/izi) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

I fully agree with the proposal :)



I also think that alignment of assignations should not be forced
(PHPCodeSniffer throws a WARNING atm).



I also like the possibility to call functions like this:



someFunction(

    $param1,

    $param2

);



When the param is an array:



someFunction(array(

    'foo'   => 'bar',

    'spam' => 'eggs'

));



And when there's an array and other vars:

someFunction(

    array(

        'foo'   => 'bar',

        'spam' => 'eggs'

    ),

    $param2

);



Of course, PHP_CodeSniffer will have to be updated if the proposal is
accepted.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Christian Weiske-2]

Christian Weiske (http://pear.php.net/user/cweiske) has edited the proposal for RFC::Coding standard enhancements.

Change comment:

Removing superfluous spaces at the beginning of code lines - they were a
leftover from the original http://wiki.pear.php.net code.

Please review the proposal:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Chuck Burgess-2]

Chuck Burgess (http://pear.php.net/user/ashnazg) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

We should be cognizant of where it currently states "must be" or "are to
be" (required) versus where it states "may be" or "can be" (allowed).



I think many of the ideas came about as ways of dealing with the 85-char
limit (? is it 80 or 85 ?) combined with Codesniffer's rigid interpretation
of spacing inside parentheses and after commas.  "No space after open
parens", "only one space allowed after comma", ... I don't think these are
explicit restrictions named in the CS, but they are implied by the code
examples.  Combine these with long code lines and the 85-char width limit,
and you get haphazardly creative to meet all the restrictions.  



In some of my own work, the only way I could split long lines without
violating those two spacing rule examples above was to split method-naming
calls on the arrow:



-|    $myLongObjectName->myExtraLongMethodName($firstArg, $secondArg);



becomes:

-|    $myLongObjectName->

-|        myExtraLongMethodName($firstArg, $secondArg);



Had the CS _explicitly_ allowed me some leeway in spacing, I could instead
use the "function arguments can be on separate lines" option, in any of
these ways:

-|    $myLongObjectName->myExtraLongMethodName(

-|        $firstArg, $secondArg

-|    );

==========

-|    $myLongObjectName->myExtraLongMethodName(

-|        $firstArg,

-|        $secondArg

-|    );



So, to me, the key to us changing the CS boils down to how we _state_
these "rules" vs "allowed possibilities".  By opening up some new "allowed
possibilities", we solve the "_implied_ rigid spacing" issue we have in our
current CS.



In the case of personal preference colliding with some of the 4-space
indention usage, maybe our "requirement" can be "at least 4" while
"allowing more spacing for personal preference readability".  It seems to
me that in these cases, lack of at least 4 spaces is what hinders
readability, not necessarily that exactly 4 reads better than maybe 6 or 8
given a particular example.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Matthew Weier O'Phinney-2]

Matthew Weier O'Phinney (http://pear.php.net/user/weierophinney) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

I agree with all, with the same exception as Philippe Jausions -- I'd
prefer that the ending paren be on the same line as the
condition/parameter, and the opening paren by itself on the following line.
This makes it easier to visually see the start and end of a block as the
braces align.



So,



if ($var

    && $foo

    || $bar)

{

}



and:



public function callSomeRidiculouslyLongMethodName(

    $param1

    $param2)

{

}

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Till Klampaeckel-2]

Till Klampaeckel (http://pear.php.net/user/till) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

I have a general question.



Will your proposed changes "open the coding standard" so people are able
to relax a bit, or will your proposal imply new rules which add CS errors
to all existing code which has been free of CS issues up until now.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Christian Weiske-2]

Christian Weiske (http://pear.php.net/user/cweiske) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

Response to Till:



The enhancements I propose extend our possibilities. Many of the suggested
changes are listed because the current CS do not allow such code layouts.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[tfk]

On 7 Mar 2008 19:09:23 -0000, Christian Weiske <cweiske@...> wrote:
>
>  Christian Weiske (http://pear.php.net/user/cweiske) has commented on the proposal for RFC::Coding standard enhancements.
>
>  Comment:
>
>  Response to Till:
>  The enhancements I propose extend our possibilities. Many of the suggested
>  changes are listed because the current CS do not allow such code layouts.

Nice, that's what I wanted to hear. :-)

Have a great weekend!
Till

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

[Paul M Jones]

Paul Jones (http://pear.php.net/user/pmjones) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

I have a suggestion on the "how-to" of splitting long if() conditions.  I
think we should encourage that the conditions be expressed as variables,
and then use those variables in the if() condition, so as to keep the
condition set all on one line.



Given the original example, that would translate into something like the
following:



    $is_foo = ($condition1 || $condition2);

    $is_bar = ($condition3 && $condtion4);

    if ($is_foo && $is_bar) {

        // ....

    }



This has the benefit of "naming" the condition sets so they are easier to
distinguish, and splits the different condition sets into readable chunks.
Doing this should greatly reduce the need for splitting if() condition sets
across multiple lines.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Michael Gauthier]

Michael Gauthier (http://pear.php.net/user/gauthierm) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

Is there a reason for putting the operators at the beginning of the next
line instead of the end of the previous line?



I don't mind much one way or the other and I do want a defined standard on
way or the other Just curious why this style:



if ($condition1

    && $condition2

) {

    // code

}

 

was chosen over



if ($condition1 &&

    $condition2

) {

    // code

}

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Craig Constantine-4]

--On March 7, 2008 20:48.25 +0000 Michael Gauthier <mike@...>
wrote:

> Is there a reason for putting the operators at the beginning of the next
> line instead of the end of the previous line?

my opinion:

1) during developement, it's trivial to comment out a line (except of course
the first line) and still have syntaxically correct code

2) it keeps the logic of the operators up front where they're not forgotten.
you can scan the left edge and see AND AND AND... with the actual expressions
neatly aligned. If the operators are at the right, you have to visual look for
them after the expressions

-c


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

[Christian Weiske-2]

Christian Weiske (http://pear.php.net/user/cweiske) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

Answer to Michael:



I chose

> if ($condition1

>     && $condition2

over

>if ($condition1 &&

>    $condition2

because you can easily comment-out conditions in the first version, which
is really helpful when debugging or programming at the source location in
general.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[Philippe Jausions-2]

Philippe Jausions (http://pear.php.net/user/jausions) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

Might want to add something regarding ternary operator as well then...



$a = ($test)

     ? $yes

     : $no;

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

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

[shangxiao]

>
> I chose
>> if ($condition1
>>     && $condition2
> over
>>if ($condition1 &&
>>    $condition2
> because you can easily comment-out conditions in the first version, which
> is really helpful when debugging or programming at the source location in
> general.

What about if the indentation is reduced to make the conditions line up?

if ($condition1
 && $condition2) {
}

--
    David Sanders
    shangxiao

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

[David Sanders-7]

David Sanders (http://pear.php.net/user/shangxiao) has commented on the proposal for RFC::Coding standard enhancements.

Comment:

I already do all of these suggestions anyway, mostly to meet the archaic
line length rule.  However aligning blocks of code is something I can't
live without ;)  In addition to aligning assignment statements you might
also want to think about arrays that have been split over several lines:



class Foo

{

    public $some_really_long_array = array(

        'option_a'   => 'blah',

        'foo'          => 'bar',

        ... etc ...

}



...and of course splitting regular arrays with indentation.



With regards to splitting method calls, I like Chuck's idea of putting the
method name on the next line.



But my question here is why do we still need 85 characters as the limit?
Is it because code might get emailed?  We're not living in the 1980's
anymore... so viewing and printing don't seem to be an issue.  This came
about again for me with File_Infopath when I started to add Xpaths which
pushed the line length right out past 85 chars.  It was much more readable
to have it all on the one line rather than concatenate strings together on
separate lines.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=538

--
Sent by PEPr, the automatic proposal system at http://pear.php.net

--
PEAR Development Mailing List (htt