[PEPr] Comment on RFC::Coding standard enhancements
| From: | Chuck Burgess | 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