8. NEVER create a file of useful functions, even if it's called helpers.php
This smacks of such a broken thinking process, it makes my teeth itch.
If you have commonly-used functions, they should be integrated with
the commonly-used parts of your code.
Example function used for debugging:
function preint_r($arr) {
echo '<pre>';
print_r($arr);
echo '</pre>';
}
Where would something like this fit, if not a general helpers.php type file?
No, it's moving debugging into a discrete, well-understood debugging package (Xdebug) rather than jumbling it together with a bunch of unrelated stuff in a big grab bag labeled "Miscellaneous".
Maybe if it's used solely for debugging, but there are cases where simple functions aren't easy to place. Consider implementing the array_column function for pre-5.4 PHP. Or things like method pull, index grouping, or array_select_keys functions.
What helper library should a function like the following exist in?
function array_select_keys(array $dict, array $keys)
{
$result = array();
foreach ($keys as $key) {
if (array_key_exists($key, $dict)) {
$result[$key] = $dict[$key];
}
}
return $result;
}
I have a similar dilemma with some of my helper functions. For example, I have starts_with(), ends_with(), and contains() for super easy string comparisons, is_between() for numerical comparisons, and custom implementations for a few built-in functions such as hex2bin() that don't exist in older versions. These are so general in scope that it would be awkward to place them in their own \Namespace\Class.
array_intersect_key does not do the same as array_select_keys. You can emulate it using array_intersect_key, but either in a more confusing or slow way.
In either case, that wasn't the point. This is a basic kind of functionality that doesn't belong to any particular class in most code bases. So in this case, having a class of 'helper' functions like these isn't bad.
array_intersect_key([], array_flip([])); is pretty idiomatic actually lol, but that's PHP for you.
The point still stands, though, that you shouldn't put array_select_keys into a php file filled with other helper functions. array_select_keys would go perfectly into a helper class called ArrayHelper with a bunch of other array convenience functions.
I'm pretty sure the author was talking about a helpers.php file like this:
myGetPlaintextUserPasswordFromGET();
encryptPasswordMD5(); //don't use this one anymore
connect_to_my_mysql_database(); //complete with hardcoded values
increment_for_loop();
my_input_sanitizer();
encryptPasswordSHA1(); //don't use thiS!!!
my_improved_input_sanitizer(); //use this one from now on!!
add_user_to_database();
getCharacterAtPosition();
generate_a_random_number_between_one_and_ten();
show_user_alert();
encryptPasswordSHA1_withsalt(); //USE THIS OnE!
myConvertEmoticonToSmiley();
...
The point still stands, though, that you shouldn't put array_select_keys into a php file filled with other helper functions.
It doesn't stand. There's absolutely nothing wrong with having a file with simple helper functions.
ArrayHelpers::array_select_keys();
is in no way better than
array_select_keys();
There is plenty wrong with the helpers file you described at the end of your post. But it's because those functions break basic programming principles, not the fact that they happen to be simple functions in a file (and most of them are not even simple).
ArrayHelpers::array_select_keys() makes it obvious that array_select_keys() is a user defined function.
ArrayHelpers helps me never wonder about where to find an array convenience function. ("array_select_keys() must be in the ArrayHelpers class" vs. "Hmm...where is that function...ugh ok let me run a find on it...oh there it is, right in between create_html_tag() and get_primes()").
ArrayHelpers lets me do lazy loading, so instead of loading everything from encrypt_password() to get_cookie_val() to do a simple task, I only get some useful array functions. Related to that, ArrayHelpers adheres to the interface segregation principle, so my function that I'm using array_select_keys() with doesn't have to know about functions that don't apply to it.
AutoHelpers helps keep my files small and maintainable. You know we've all seen helper.php files that are so monolithic that they have to be broken up with separators like this:
Just to make them somewhat readable. I mean, come on, you know you've seen that.
ArrayHelpers lets me avoid obnoxious require() statements.
ArrayHelpers can be used on pretty much every future project ever without modification, so I know it will work out of the box. helpers.php on the other hand? Well, oh crap, some app-specific helpers just happened to weasel their way in there, guess I better delete them. OOPS! Deleted a semi colon by mistake and now my whole app has borked itself.
I mean, what's not to like? A few extra characters?
You know we've all seen helper.php files that are so monolithic
Yes. This has nothing to do with flat functions vs. classes. I've seen 'helper' classes get shitted up just as much as function files.
My point is that it doesn't matter. Many projects don't require heavy portability, and in either case, bootstrapping a namespaced shim next to your autoloader isn't a problem.
I'm not arguing that if you have a very extensive functions library, you should separate it out. I totally agree that you should. But saying 'NEVER MAKE A FUNCTIONS FILE NEVER EVER EVER ON PAIN OF DEATH' is silly.
IMO that should be a method on a Logger object. Personally I have a method that does a similar thing called 'inspect'.
Even better: you should write to a log file instead of to the screen (at debug level) for such things so you don't have to remove your (useful) debug statements before committing.
