> Just wanted to see what you think of the strictness of Buxa,
> according to
> their PHP guidelines:
> http://www.buxaprojects.com/en/php_coding_guidelines.htm
>
> In their oppinion stuff like the short PHP init "<?" or
> inline echo "<?=
> $var ?>" is forbidden.
> Do you people code that strict?
I like some of their ideas, but I disagree about short tags.
I always use <?php ?> and <?= ?> but never <? ?>
I like the _idea_ of an organized naming convention, etc, but I think theirs
is a bit overkill for example:
Buxa_Db
Buxa_Db_Table
Buxa_Controller
Mapping to directories is silly like that.
\includes\classes\db.class.php
\includes\classes\table.class.php
\includes\classes\controller.class.php
We do a lot with Ruby here for the backend, and PHP for the front. So we
adhere loosely to the Rails/ActiveRecord way of things like:
end_user.class.php
Which directly corresponds to a SQL table of "end_users" (note the plural).
Within there we have $id, $_stamp, and $created_on which are popular in
rails Active Record.
We have a base.class.php containing the above, and everything else extends
from it.
We also are in love with the PHP __call, __set, __get methods to save
thousands of lines of redundant (useless) code.
We try to stick with lowercase filenames.
define's are all capitals, so are class constants.
I dislike their use of the _ char for protected things.
We use ' and " properly... (use ' most of the time as no pre-processing
required)
Uppercase SQL statements I agree. I've been meaning to write a tool that
will go through and fix any lowercase ones, but it's not so trivial ;-p
For long SQL, we just carriage return, none of that . appending crap.
We always try to "LIMIT 1" where possible.
We do the multiple line array thing. Makes it easy to read. In both formats
they show.
We use PHPXRef as our documentor, so we follow those basic @ tags.
We don't pass by reference, as there's no need anymore AFAIK. PHP handles
all that intelligently.
Big fans of the ()?: operator.
Only use { } when there are more than one statement to enclose. Our pages
tend to be in the KLOC range, so pruning out unnessesary white space/lines
helps a lot.
Big fan of the switch statement over multiple if/elseif/else
We tend to do the first { on the next line, rather than the same line.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
