Underscore method prefix

Question

I\'ve been examining the code of CodeIgniter and CakePHP and I noticed that some of the methods in their classes are prefixed with an underscore _ or a double u

Answer 1

I have a use case for this that is my own preference. I will often write traits that are intended to honor a specific interface, although since traits cannot directly implement an interface, I will designate which interface the trait satisfies in the doc block comment, and prefix protected and private methods that are not related to the interface with a single underscore. This lets you pretty easily follow which methods are provided to satisfy the contract (interface), and which are supporting methods. Eg:

interface Foo {
    public function bar(array $args = null, array $flags = null);
}

The trait below's purpose is to satisfy the requirements of the Foo interface, but only one of it's methods are needed to do so. For clarity, the protected methods are prefixed. Even if they are made public by extension later, this still indicates that they are not contractually dependent by interface, and should not be assumed to be anything relevant.

/**
 * @satifies Foo
 */
trait FooTrait {

    public function bar(array $args = null, array $flags = null) {
        $this->_handleArgs($args);
        $this->_handleFlags($flags);
    }

    protected function _handleArgs(array $args = null) {
        if (is_null($args) {
            return;
        }
        //do something with the args
    }

    protected function _handleFlags(array $flags = null) {
        if (is_null($flags) {
            return;
        }
        //do something with the flags
    }
}

You can then satisfy the interface by implementing it on a class and using the corresponding trait with no additional work.

final class ConcreteFoo implements Foo {
    use FooTrait;
}

This keeps things very loosely coupled, and makes it possible to pretty easily integrate with other classes from other libraries or frameworks that do require a chain of inheritance without having to convolute your logic with a bunch of adapter classes.

---

My IDE (Netbeans) grumbles about this as a violation of PSR-1. As PSR-1 does not directly affect execution and it is arguable as to whether this is a more readable approach or not, I could really care less. I do try to follow all of the PSR's that directly affect execution though.