> Also developing PHP extensions is much different than developing PHP.
> In PHP extensions the code itself is much more encapsulated, in PECL
> individual package development is encapsulated. As long as the code
> follows the php naming conventions (for exported functions), it can
> interact nicely with the other packages. Forcing developers to use one
> coding style in their individual projects will needlessly limit
> contributions to PECL, and have no external benefit.
Also, don't forget that a PHP extension is often a small part of a much
larger project that may also have Perl and Python support, for example.
It would certainly be beneficial if the PHP part of such a project could
be part of PECL and forcing the authors to adhere to our highly arbitrary
coding standards is not a good idea in such a case.
I think people are getting way too worked up over coding standards. They
should be treated as a guideline not as an absolute, even in the core PHP
code. Small deviations from the standard makes absolutely no difference
to the readability of the code.
if(blah==SUCCESS) vs if(blah == SUCCESS)
Nobody is going to get get that confused, but yes, technically this is a
CS violation. And it appears at least 56 times in the current 4.3 code:
10:00am thinkpad:~/php43> grep "==SUCCESS" */*.c */*/*.c | wc -l
56
And Jani, if you go through and clutter up CVS with fixes for each of
those I will whack you with a smelly trout.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
