Re: hope to finish the coding standard
| From: | Stig S. Bakken | Date: | Thu, 27 Dec 2001 09:12:15 +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-3708@lists.php.net to get a copy of this message | ||
Alexander Merz wrote:
>
> > I think the coding standards can be relaxed a bit. Their goal is to
> > create a common set of rules. But this community has to listen to its
> I already wrote in a lot of mails that the coding standard is handled relaxed
> in practice.
>
> > (potential and regular) contributors. There are two issues that receive
> > most of the complaints:
> Please go through the archiv and check, which potential contributers want to
> change it.
> So far I remember there are only two, which said, we are not willing to
> contribute our classes due to the cs.
You are assuming that they all announce their non-participation on the
mailing list.
> > I think it's time to extend (1) to allow both studlyCaps and
> > under_scores. IMHO the strict studlyCaps rule has proven to be
> > sub-optimal for this community. If PEAR was a Java repository it would
> Which community? Allow both style it is optimal for devs, but really
> non-optimal for the user.
> > people complain, we cannot simply ignore them forever. That's just
> > arrogant.
> We are already arrogant. We decided not to commit phplib as a whole, or
> binarycloud, because we want no complete frameworks in PEAR. But a lot of
> people wanted it.
Irrelevant. These decisions were not made because someone did not like
binarycloud, but because someone has an idea of how PEAR should evolve.
> At least it is a question of discipline. If you are not willing to adopt your
> code to cs, why should you willing to maintain and to document your class?
> Matching CS isn't so complicated espe. with a good editor. I.e. changing MP3_ID
> to match the cs requires only 15 min, but writing phpdoc and testing the
> changes 60 min. The CS stuff is a big column for quality keeping and being
> userfriendly.
I agree, the coding standard is important for quality, but from what
you're saying it sounds like I have suggested to ditch it. I haven't, I
suggested making a compromise. A compromise is for both developers and
users, since it will probably attract more good packages to PEAR.
- Stig