[PEPr] Comment on RFC::Coding standard enhancements
| From: | Jeff Moore | Date: | Sat, 15 Mar 2008 23:39:27 +0000 |
| Subject: | [PEPr] Comment on RFC::Coding standard enhancements | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-49430@lists.php.net to get a copy of this message | ||
Jeff Moore (http://pear.php.net/user/selkirk) has commented on the proposal for RFC::Coding standard
enhancements.
Comment:
I agree that keeping lines under 80 characters is important. However, I
think it is possible for a coding standard to be over-specific. Maybe the
mechanics of splitting lines is over-specification?
That said...
Split function definitions onto several lines:
If you are going to use more than one line, why not put each parameter on
its own line?
Also, I think the preferred choice is not to have so many parameters. See
Martin Fowler's Refactoring book for the code smell "long parameter list."
Rather than specify how to properly format the code smell, I'd rather see
avoidance when possible and embarrassment when not.
Split function call on several lines:
Same goes here. one per line when necessary. Avoiding long parameter
lists avoids long call lists. Use temporary "explaining" variables and
"explaining methods" instead of complex formatting. (See Kent Beck's
implementation patterns book as well as the chapter in the Refactoring book
on making method calls simpler.)
Split long if statements onto several lines:
While not listed as a code smell in the refactoring book , complex
conditionals should have been there. (It is defined as a smell in
Refactoring to Patterns). Again, the solution is simplify conditional, use
explaining variables, etc. See the Chapter in the refactoring book on
making conditionals simpler.
Alignment of function parameters:
Alignment of assignments:
I've always found this kind of alignment to be more work than its worth.
Is PHP_CodeSniffer really going to warn on these? I sure hope not. These
are best as optional or personal preference, and thus not in the
specification of standards.
Summary:
Rather than document the proper way to format hard-to-understand code
fragments (code smells) and rather than burden the standard with hopefully
rare edge cases, I think its best to leave them undocumented and thus
slightly uncomfortable to use and slightly discouraged.
I think specifying PHP_CodeSniffer edge cases dilutes the usefulness of
the standard for the cases that matter more. I don't want to have to
become a code formatting lawyer when I'm coding.
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