Re: hope to finish the coding standard
| From: | Tomas V.V.Cox | Date: | Fri, 21 Dec 2001 05:48:22 +0000 |
| Subject: | Re: hope to finish the coding standard | ||
| References: | 1 2 3 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-3620@lists.php.net to get a copy of this message | ||
Jon Parise wrote:
>
> On Fri, Dec 21, 2001 at 04:52:21AM -0000, Richard Heyes wrote:
>
> > > It's late at night, hm, more early in the morning, so don't wonder...
24H coding standars war ;-). Let's go.
>
> For the most part, I agree, as well.
>
> The point of my previous post was to introduce a change to the
> coding standards that effectively made them more of a guideline
> than a requirement. I also introduced the requirement that all
> changes to source code be made using the same style as the
> original code.
The most controversials:
a) identing
b) naming classes
c) naming methods
d) brackets in functions definition
e) brackets in control structures
As you said a) can't change because it will force the user to change
it's editor configuration, b) can't change or we will end polluting the
name space, d) is enough little not to follow it and e) it's more
confortable to read.
That takes us to c): methodName() vs method_name()
This c) point is the only one point that will be seen by PEAR users
(where PEAR user = a developer who uses PEAR classes) and as Alex
pointed they seem to agree with the actual method naming. We are here
for developing stuff for PEAR users or not? And i guess that they won't
be very comfortable if we force them to do things like:
$db->setErrorHandling(..);
$foo->parse_error(..);
$db->executeMultiple(..);
$foo->print_error(..);
> Ideally, everyone would follow the guidelines and all of the PEAR
> could would conform. The reason I'm suggesting this change is to
> encourage more code to be contribute to the archive without
> absolutely requiring submissions to be reformatted.
Do you really think that allowing c) is the only key for getting that
amount of people not to contribute?
IMO PEAR will never reject any good piece of code even if it doesn't
meet the coding standars. For a) I posted a tab->spaces script, b) is a
must, d) and e) aren't really so important and for c) (again) the class
can go into PEAR with no problems and perhaps marked as "beta" until
others want to do the job for you (you can see this example with the
Net_NNTP class).
Tomas V.V.Cox