Live data from Hacker News

PHP Commandments

biasedphp.com

31–40 of 117 posts

Re: PHP Commandments

#31
post #19

Wow, this guy really hates CakePHP. If you know what you're doing and don't just presume Cake has done it for you, none of those problems should exist.

I find that to be very true. Seems a lot of amateur programmers pick up CakePHP for one reason or another without actually knowing PHP and try to drive every screw with the one hammer they have. When everything's suddenly broken they blame the hammer.

EDIT: Although I suppose the author's point of view is from the outside-in where he's tasked with cleaning up the mess that amateurs leave behind and has a bias against it.

Re: PHP Commandments

#32

Is sending email really that slow? In my experience, it just writes something to a local mail queue if your front ends can send email.

Yes it's slow in that it's a blocking call. Since it takes more than a fraction of a second put a message in the mail queue, it'll _feel_ slow.

Re: PHP Commandments

#34
post #16

Can someone help me understand why a "helpers" or "utilities" file of functions is so bad? Asking humbly because I do that and don't yet understand why it's bad / the alternative.

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.

Re: PHP Commandments

#35
post #14

Earlier quoted context omitted.

>Where would something like this fit, if not a general helpers.php type file? In debugging.php alongside with other debugging helpers?

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 (ar…

[deleted]

Re: PHP Commandments

#36
post #12

Are people still using PHP without frameworks these days?

The most painful thing about the years I spent working with PHP was having not even understood that web development frameworks existed. The little slice of the development world I existed in had absolutely no exposure to the concept... after switching to Python and only then discovering the concept, most of those PHP memories, in addition to being painful, became simultaneously embarrassing.

Re: PHP Commandments

#37

Is sending email really that slow? In my experience, it just writes something to a local mail queue if your front ends can send email.

It can be that slow, yes. There is no assurances that will be fast, you're just hoping it will be.

Now you could argue "that's true of anything!" but in general you are forced to depend on local IO/CPU/RAM otherwise your site is struggling in general, by adding DNS/SMTP/etc you're just adding more "stuff" that your site relies upon.

Plus SMTP servers are "allowed" to go offline for short periods. The client should try to resend the email 2-4 additional times before giving up. Clearly a PHP script cannot do that.

Re: PHP Commandments

#38
post #16

Can someone help me understand why a "helpers" or "utilities" file of functions is so bad? Asking humbly because I do that and don't yet understand why it's bad / the alternative.

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

Re: PHP Commandments

#39

Is sending email really that slow? In my experience, it just writes something to a local mail queue if your front ends can send email.

Yeah that one caught my eye in an otherwise good list too. Typically sending email via PHP's mail() function is only slow if your server is not configured correctly: http://www.alphadevx.com/a/372-Fixing-slow-performance-of-se...

Re: PHP Commandments

#40
post #16

Can someone help me understand why a "helpers" or "utilities" file of functions is so bad? Asking humbly because I do that and don't yet understand why it's bad / the alternative.

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.

Post reply on HN