PEAR coding standards

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

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