PEAR Coding Standards Change?

Since a couple of months now, I've been involved with PEAR as a contributor. Contributing to PEAR means adhering to the PEAR Coding Standards. Their standards have actually been thought over, and using them for projects (also outside of PEAR), leads to consistency, and makes it easier for many developers to understand each other's code.

Code can be scanned and checked for conformity using the PHP CodeSniffer package.

It took me a while to get rid of my old coding habits & pick the standards up to be second nature, but I'm very happy with the results now. Except for one rule. It has bugged me to the point that I've decided to ask the PEAR Group to reconsider it.

It's about denying developers to prefix their protected methods with an underscore.

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

Prefixing Methods

Some developers (like me) find it helpful to distinct 'inner methods' and public interfacing methods visually, by prefixing them with an underscore:

<?php
// Please just let the outside world: shoot,
// and let the class worry about things like breathing properly
_load() {}
_stopBreathing() {}
_aim() {}
_fire() {}
_resumeBreathing() {}
shoot() {}
?>

Alphabetically grouping functions that don't concern the outer world, comes in handy with the drop-down lists many IDEs provide. Especially with large/unknown/forgotten projects, it can provide quick insight into the inner workings of a class.

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.

Privates Are Dead. Long Live the Protected!

Private methods are becoming a minority. The need for them decreases as classes often need to be fully extensible.

Faced with a movement where private methods are diminishing and protected methods are taking over, this leaves us mainly with two types of methods: protected & public.

PEAR coding standards do not allow us to prefix protected methods with an underscore. Resulting in:

<?php
// Please just let the outside world: shoot,
// and let the class worry about things like breathing properly
load() {}
stopBreathing() {}
aim() {}
fire() {}
resumeBreathing() {}
shoot() {}
?>

Which in some IDEs & minds is very OK. It's mostly an issue of habit/taste. 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.

Can't protected methods be redeclared as public?

Yes, and this a compelling argument against my case, because once you redeclare a method as public, it still is prefixed with an underscore!

Take into consideration that private methods currently must be prefixed with underscores. Should you follow through this logic, one could argue that protected methods explicitly meant/allowed to be redeclared as public: mustn't have an underscore, but all others should! (let's make it clear: I am not arguing this!).

But you see there's a need for flexibility when it comes to protected methods.

In reality. Should need a protected method to be interfacing with the outside world, you have to take orthogonality into account, and you're probably better off wrapping the protected method inside a public method anyway.

Still, these cases that I speak of are rare. In 99% of the cases, you will find that protected methods are just replacing the role that private methods used to have.

Concluding

So I'm pleading here for PEAR CS to allow developers to choose their own private & protected method names (whether prefixed with underscores, or not).

The discussion can be viewed here:

www.nabble.com/PEAR-Coding-Standards-question-tt19054118.html#a19054118