Asking humbly because I do that and don't yet understand why it's bad / the alternative.
Asking humbly because I do that and don't yet understand why it's bad / the alternative.
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.
$username = InputSanitizer::getInstance()->getPostData('username');
There. Now it's OO ;P. $username = array();
exec('java sanitize.class ' . escapeshellarg($_POST['username']), $username);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.
I'm the one saying that strict OO is bad because it's verbose and its slower than the alternative.
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.
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.
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.