Coding Standards
How far in should your code be indented? What about class names - should they be capitalized? Do we put the opening brace of a function on its own line or not? Somebody just tell me!
With all the possible combinations of coding styles, you can’t expect there to be only one. Certainly, cases can be made for the “one true brace” style as well as any other and they all may have their merits.
There we have at least eight ways of forming a block of code, and that’s not the only issue to consider.
- Variable naming
- Class naming
- Quote types
- Comment style
- White space
- Line length
- …on and on
In the end it comes down to consistency. Pick something and do it everywhere in that project. Of course, it would make things easier if all of your projects were done in the same style but don’t be afraid to experiment.
And if you’re part of a team, you may not have a say anyway. Everyone on the team should be coding with the same set of guidelines so that the project looks as if it came from one mind.
Perhaps the most widely used standards today are the Zend Framework Coding Standard and PHPDoc (tutorial here). Zend Framework uses the PHPDoc format for inline documentation by the way.
Learning those two will make it easy for you to slip right into just about any project. You’re likely to find that they’ll vary only slightly if at all.
Matthew Weier O'Phinney wrote,
I’d hesitate to say that ZF coding standards are the most widely used; I’d give that honor to PEAR. ZF standards actually build on PEAR standards (which in turn were built on Horde standards).
Also, I’d call phpDocumentor a standard for annotations, not for coding. phpDocumentor is actually specifically a tool for compiling API documentation _from_ those annotations (and a little code reflection). As an interesting aside, PHP itself has defined a token for doc blocks, which basically standardizes their use even within the PHP interpreter.
Link | January 24th, 2009 at 07:53
php|nightly wrote,
Good points. Perhaps I should’ve said the ZF standards are the most recommended these days as that’s how it seems to be in the public forums (my experience). Of course, just because something is talked about doesn’t mean it’s being used the most.
PEAR coding standards should have been mentioned. Here’s the link
http://pear.php.net/manual/en/standards.php
And I threw in PHPDoc because you see it nearly everywhere and is required by some but yes, it isn’t part of the code (aside from being in the same file). It can be helpful when trying to get an overview of a method or class, though. Maybe it should’ve been an entry on its own.. and maybe it will be.
Thanks for the comment. Always good to have clarification.
Link | January 24th, 2009 at 16:18
Chuck Burgess wrote,
Matthew is spot on… the docblock format itself is more of the “annotation standard”, and phpDocumentor expects docblocks meeting that standard… a.k.a. “follow the convention”.
A great tool to use once you have chosen/defined a spec is PHP_Codesniffer [1]. It parses your code to enforce the coding standard’s rules, highlighting things that don’t follow the standard.
[1] - http://pear.php.net/package/PHP_CodeSniffer
Link | January 24th, 2009 at 19:26