As I said multiple times: I'm open to changes. I would be very
happy, if you could set up sth. like an RfC describing a less
strict coding standard that you think is good for PEAR, since I
currently don't have the time to sit down and write something
down in a proper way.
I'm very sure, that lots of other people on this list are very
interested in improving the guidelines, so there will be
comments on your work for sure.
- Martin
Alright, quick RFC (sorry, don't have time to prepare a formal one either):
1. I propose that PEAR be split into CORE and an EXT (or CONTRIB), where CORE is the stuff we've already got, and the stuff that has to go through a rigorous approval process. Basically, Java's standard library. EXT would be code that conforms to a certain level, but less so than CORE. Duplication would be allowed in EXT, but we would still be talking about classes, not apps or forums or builders. EXT could be compared to Perl's CPAN.
I like the idea someone just had on here about distributing the CORE with PHP, but not EXT. Perl does this, and it works very well.
2. Tabs vs. Spaces? Who cares. As long as either tabs or 4 spaces are used, it's all good. Tab length can be set in almost any modern editor, and 4 spaces is already the PEAR standard. I don't think a few rebel classes with tabs are going to completely overturn the system. ;)
3. Use ample spacing. I prefer using the "$obj->method ($p1, $p2);" syntax while some prefer "$obj->method($p1,$p2);". As long as its legible. I'll stick with my way, you stick with yours. There will always be a level of subjectivity about this that will creep its way into the approval process for classes. That's fine, but I think we should just say "as long as it..." instead of "it has to be" regarding spacing.
4. Method naming should probably be standardized in the CORE. So methodName () it is. But as for EXT, if the class has an established user base, it is unrealistic to ask them to change. method_name () isn't all that bad anyway.
5. Where to put curly braces. I say CORE stays the same, but EXT, whatever. It comes down to coder productivity. I've been doing things this way for X years, you've been doing them that way for Y years. Good. As long as you and I are both stickler enough about our ways of doing things, it encourages diligence, which is required.
6. Instead of "it has to be this way", why don't we add (on top of the initial "as long as") "it has to be consistent throughout a class or package". This should help ensure code consistency.
7. Let's try to use single-quotes whenever possible. I tested a script I wrote that had tons of quotes in it both ways, and it made a noticeable difference. We have to stay the fastest bad-asses on the web dev scene, after all. ;)
The rest of the standards I'm quite happy with, so if anyone wants to add to this about issues they have, cool. I also want to clarify, I'm not saying let's go changing the CORE stuff now, it doesn't need to be. There's no reason to. So with the changes I'm proposing, existing apps using PEAR will be unaffected. Also, the benefits of a centralized place for EXT classes to go is that a project can say "we rely on classes X, Y, and Z, which are available from the PEAR extensions library."
Lux