PEAR Coding Standards Changed!

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).

More info

If you would like to know more about the background of this 'story'.

Proposal

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>

wrote:

> 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
[https://kevin.vanzonneveld.net][3]

Finally

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.

More info

Proposal

Links

Finally