> 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
