[PEPr] Comment on RFC::Coding standard enhancements

From: 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

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