In another article I've told you about how I would like to see one rule removed from the PEAR Coding Standards. This rule would allow developers a bit more flexibility, while staying true to the convention.
At first the discussion was between the PEAR developers on the mailing list, but as this is somewhat a matter of taste, the opinions were widespread. The PEAR group adopted the issue into their own meeting, silencing the discussion on the mailing list.
And now it seems they have decided to indeed omit a specific declaration on prefixing private or protected members with an underscore from the Coding Standards.
Effectively leaving every PEAR developer the freedom to prefix their private & protected members however they want (or not).
If you would like to know more about the background of this 'story'.
Hi Joshua, First of all, thanks for your time. On Fri, Aug 22, 2008 at 12:59 AM, Joshua Eichorn <josh at bluga dot net>
> If you can email me what you think it should look like that would be > helpful. But i will bring it up at the meeting (already added it to the > agenda) OK, I'll try to be as concise as possible, though my English may fail me from time to time, and I should probably be sleeping already ; ) To clear one potential misunderstanding: My proposal is not about forcing people to prefix every protected method with an underscore. It's about allowing them to do so. Private methods are becoming a minority. The need for them decreases as classes often need to be fully extensible. Though protected methods can indeed be redeclared as public (one could even argue that protected methods explicitly meant/allowed to be redeclared should not have an underscore, other should); these cases are rare. And in practice, protected methods are often replacing the role that private methods used to have. Some developers (like me) find it helpful to distinct 'inner methods' and public interfacing methods visually, by prefixing them with an underscore: _load() _stopBreathing() _aim() _fire() _resumeBreathing() shoot() Distinguish functions that don't concern the outer world by alphabetically grouping them. This comes in handy with the drop-down lists many IDEs provide. But faced with a movement where private methods are diminishing and protected methods are taking over, this leaves us with two types of methods: protected & public. PEAR coding standards do not allow us to prefix protected methods with an underscore. Leaving us with: load() stopBreathing() aim() fire() resumeBreathing() shoot() Which in some IDEs & minds is very OK. It\'s mostly an issue of habit/taste, referring to your bike shedding project (red indeed is a fine color). Having thrown overboard lots of my old habits, incorporating PEAR's, I definitely understand the need for convention. But since quite some developers use this concept as a profound tool add order to chaos, such a small thing could make for a big difference in coding experience. It would at least for me at the moment. So I'm pleading here for PEAR CS to allow developers to choose their own protected method names (whether prefixed with underscores, or not). Hope this wasn't too long! -- Met vriendelijke groet / Kind regards, Kevin van Zonneveld [http://kevin.vanzonneveld.net]
A short note confirming their decision
What started it
Well, just like to say that I'm very happy to see that in PEAR - as an organization - it's actually possible to make these things hapen, even though you only have one PEAR contribution to back you up.
So thank you PEAR, and thank you PEAR Group.