[PEPr] Comment on RFC::Coding standard enhancements

From: Date: Fri, 07 Mar 2008 18:00:28 +0000
Subject: [PEPr] Comment on RFC::Coding standard enhancements
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-49309@lists.php.net to get a copy of this message
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

« previous php.pear.dev (#49309) next »