Re: relaxing studlyCaps requirement?

Quoting "Stig S. Bakken" <ssb@alltheweb.com>: > I think we should consider relaxing the studlyCaps requirement and > change it from a requirement to a recommendation. These things seem to > invoke a lot of hard-felt feelings in people, and I don't see any reason > to be too stubborn about this at the expense of some very good contributions. > > This does _not_ mean we're going to start relaxing every other > requirement, it's just that this one issue has caused a lot of funny faces. > > Opinions? Short answer: no, don't. Long answer: Argh. Here we go again... First off, I'm going to say what I want PEAR to be, because I think that impacts a lot of this: I want PEAR to be a robust, useful, well-engineered library of code for people writing PHP scripts and applications. I want it to be a solid set of re-useable building blocks. I don't want it to be CPAN; see Jon's comment about perl abandoning that in favor of a smaller - and I'll bet more consistent - SDK. Coming from that perspective, it is more important to me to maintain the level of quality of code in PEAR than it is for Joe Shmoe to feel like he can contribute any bit of code that he wants to (yes, that's an extreme example). Consistency is part of the level of quality of a library like this. And naming conventions are at the heart of - and the most important part of - consistency. Therefore, I think we need one. And studlycaps is what we have right now, so I say we stick with it. Is it "the one true way" ? Hell no. It's a convention. Some of the stuff in CODING_STANDARDS - yes, even in Horde's CODING_STANDARDS - isn't how I naturally did stuff. I've adjusted. That said, I have no problem with being one of a set of people who will take submitted code and bring it into spec. I see no reason to _reject_ a well- written class because it uses different naming conventions - but I _am_ going to change them. -chuck -- Charles Hagenbuch, <chuck@horde.org> Some fallen angels have their good reasons.