News for hackers. Stuff that matters.
Re:PHP Commandments by rmrfrmrf on Tuesday April 30, 2013 @11:01AM (#5632537)
Helper files are a pain in the ass because they're usually all jumbled up and hard to maintain. In my experience with them, they come a zillion functions that are all unrelated, from input sanitization to XML processing to database initialization. Then, when you need to figure out what the hell is going on in your code, you have to wade through a forest of garbage just to figure out what the function is doing. God forbid you accidentally make a typo in ANOTHER function while editing the one you wanted -- now you've just introduced another bug without even realizing it.

Furthermore, in PHP, we devs are almost always using the same boilerplate over and over again (getting user input, etc.), so why would we use a "helpers.php" file when we instead could break out our code into more semantic, reusable chunks?

Instead, you should be creating classes (or at the very least, creating files that all have related functions, not just throwing all of your "helpers" into one file, so instead of helpers.php, you have inputSanitizer.php, htmlParser.php, et cetera).

For example, I see a lot of this kind of thing in "helper.php" files:

    function sanitizeInput($input) {
        $input = htmlentities($input);
        ...
        return $input
    }
What I personally love to do because I'm OO obsessed is use a home-grown InputSanitizer class, so now when I have a new project, I don't have to copy over my "helpers.php" file and then strip out everything unrelated to my project; I just copy over InputSanitizer.php to the new project and do something like this:

    $username = InputSanitizer::getPostData('username');
MUCH cleaner and easier to maintain. Even better: if you're using classes and auto-loading, you'll never have to worry about includes again, you simply just call the class methods or instantiate.

There's a clean, wonderful side to PHP that I think a lot of people aren't taking advantage of.

Re:PHP Commandments by tabbyjabby on Tuesday April 30, 2013 @11:04AM (#5632556)
I'd just like to note that that is not a particularly OO solution. You've essentially created a namespaced function. While this is still preferable to a bare function in a heterogenous helpers function file, it's certainly not a pure OO way of accomplishing the encapsulation of the InputSanitizer.
Re:PHP Commandments by yogo on Tuesday April 30, 2013 @11:35AM (#5632751)
This is a problem that goes all the way to the core. It isn't very good OO (some will argue PHP isn't really OO anyway) because core types are not objects. Whether you have substr(..., ...), Helper::substr(..., ...) or getSomeInstance()->substr(..., ...) it's really all the same, with maybe some added benefits if you provide some wrapper functionality as in the last case.
Re:PHP Commandments by rmrfrmrf on Tuesday April 30, 2013 @11:11AM (#5632612)

   $username = InputSanitizer::getInstance()->getPostData('username');
There. Now it's OO ;P.
Re:PHP Commandments by z92 on Tuesday April 30, 2013 @12:12PM (#5633053)
I would rather use Java in that case.
Re:PHP Commandments by rmrfrmrf on Tuesday April 30, 2013 @06:53PM (#5635398)
Your wish is my command.

    $username = array();
    exec('java sanitize.class ' . escapeshellarg($_POST['username']), $username);
Re:PHP Commandments by Shorel on Tuesday April 30, 2013 @11:33AM (#5632730)
And very fortunately so. 'Pure' OO is the madness that created Java.

Encapsulation is overrated. So overrated that you need another fancy concept like 'dependency injection' when it just gets in the way.

The static function is simple and because of that, it is good.

Re:PHP Commandments by eru on Tuesday April 30, 2013 @11:54AM (#5632913)
tabbyjabby didn't say it's bad. They just said it's not OO.
Re:PHP Commandments by Shorel on Tuesday April 30, 2013 @12:02PM (#5632977)
I know. It implies the assumption that not complying with OO is something code should avoid as a rule of thumb.

I'm the one saying that strict OO is bad because it's verbose and its slower than the alternative.

Re:PHP Commandments by hdctambien on Tuesday April 30, 2013 @12:29PM (#5633175)
I think it more implies that object oriented things should be called OO and not-object-oriented things should be called something that isn't OO.
Re:PHP Commandments by eru on Tuesday April 30, 2013 @01:33PM (#5633652)
Count me in as saying that not only strict OO is bad, but OO is a bad idea in general. At least in its usual form. You might manage to tackle something OO-like on, say, FP, and get away with it.