PEAR coding standards
| From: | Thomas Hurst | Date: | Sat, 19 May 2001 14:32:34 +0000 |
| Subject: | PEAR coding standards | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-400@lists.php.net to get a copy of this message | ||
Some comments/questions.
> Indenting
> Use an indent of 4 spaces
What's wrong with tabs? They result in (marginally) smaller code and
let the user decide on indent levels.
> if ((condition1) || (condition2)) {
> action1;
> }
I always use:
if (foo)
{
bar;
}
Because it reduces the likelhood of missing {'s and producing difficult
to trace parse errors. What's more difficult to spot deep in code:
if (big long expression that pushes this way over to the right)
bar;
}
When you're used to having the { difficult to spot anyway, or when you
expect a mostly blank line afterwards?
> Function declaractions follow the "one true brace" convention:
Why for functions (which are a LOT less common than control structures
and ergo less likely to produce unmatched {} errors) and not control
structures?
IIRC the 'one true brace' convention is for things that nest.. and
functions do nest in php :)
Besides which, it's dumb anyway..
> Inline documentation for classes should follow the PHPDoc
> convention, similar to Javadoc
It's slow as hell (looks like the author would be more at home with C++)
and horribly buggy. It also needs a php cgi binary, which is not yet
common. I'll stick with ezPHPDoc for the time being. Maybe adding php
support to an existing documentor (such as doxygen) would be a good
idea?
I seem to recall some conventions on method/variable naming too, but
they seem to have disappeared.
Of course, if someone could come up with a php version of ident(1) I'd
be much happier :)
--
Thomas 'Freaky' Hurst - freak@aagh.net - http://www.aagh.net/