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.

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.

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.

   $username = InputSanitizer::getInstance()->getPostData('username');

There. Now it's OO ;P.

I would rather use Java in that case.

Your wish is my command.

    $username = array();
    exec('java sanitize.class ' . escapeshellarg($_POST['username']), $username);

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.

tabbyjabby didn't say it's bad. They just said it's not OO.

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.

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.

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.

This definitely isn't limited to PHP. While there may be instances where 'helpers.xyz' is OK, they're very, very few and far between. When you create a file like that, you've conceded defeat at actually naming things usefully.

If 'logging.php' or something similar doesn't fit what you're doing, and it doesn't fit well with anything else in your project, and there's no other way that would fit in with something intrinsic to your app, then this might be OK. But that's kind of hard to fathom.

In my opinion, though -- while I agree that it's something to be avoided at many costs -- the real problem with this, as with many things, is overuse. I'm on at least one project right now where the unconscionable overuse of helper functions (an entire directory of them with questionable file names, actually) has turned a Django project into horrible spaghetti code.

It's definitely not an isolated incident. In all languages, if what you're doing has any kind of logical structure, it's worth taking pains to make sure things go in logical places. You'll thank yourself in the future, and so will your successors.

Since you can't autoload functions who aren't members of a class, you must include/require the file on every request, or otherwise include the file whenever you use those methods. PHP projects have, generally, abstracted the thinking about "what file does this thing come from?" by now - via the autoloader - which, as I said, doesn't work with functions. So functions, annoyingly, create a leak in the abstraction that otherwise allows us to forget about exactly what files our code lives in.

As an aside, to me, it also raises questions regarding the design of your code (how do I inject mock methods?). But that's hard to know without seeing it (if the methods are simple enough, perhaps there's just no need to mock them in your tests).

I encapsulate "helper" or "utility" logic in objects, e.g. RandomGenerator with a getRandom, which can be amazing when it comes to testing, and lets me forget about include/require'ing files.

It isn't - they should be abstracted to what they help with though. For example I have a \Helpers namespace and my autoloader brings them in as required: http://pastie.org/7743301

I don't quite agree with him on that also.

PHP is multi-paradigm, if you keep helpers functions in a way it's well structured and feels right in your project, why do not use them?

This is a personal preference, not a fact.

there's no generic "helpers". probably he meant to be more specific like htmlparsinghelper.