Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP Commandments

biasedphp.com

Post reply on HN
Print view View original

41–50 of 117 posts

Re: PHP Commandments

#41

Post by obviouslygreen »

aarondf wrote: 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.

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.

Re: PHP Commandments

#42

Post by tabbyjabby »

rmrfrmrf wrote: post #40
aarondf wrote: 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 fo…

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

#43

Post by potatolicious »

jcampbell1 wrote: post #17
citricsquid wrote: post #10

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 ' '; print_r($arr); echo ' '; } Where would something like this fit, if not a general helpers.php t…

You should install xdebug, and then var_dump will do what you want and a lot more.

Isn't that just letting someone else write your helpers.php?

Re: PHP Commandments

#44

Post by jcampbell1 »

UnoriginalGuy wrote: post #37
jcampbell1 wrote: post #13

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 tr…

I am totally confused. Who uses an SMTP server written in PHP? mail() just writes a bit of stuff into a mail queue by default.

Re: PHP Commandments

#45

Post by UnoriginalGuy »

> NEVER hash passwords with MD5/SHA-1/Hash-of-the-day

> PHPass will make life easy for yourself and keep your users' passwords secure.

MD5/3DES/SHA-1 are relatively broken. But saying "use this magical library" is really far from a solution. Who's to say that that library won't be broken tomorrow and then someone else won't write an article next week saying "don't use PHPass!"

Programmers just need to stay up-to-date with the latest trends and adjust their approaches accordingly.

> MD5/SHA-1/Hash-of-the-day is not, was not, and never will be acceptable.

MD5 was very much acceptable for the longest time. Back when everyone was using 3DES, MD5 was seen as the Bcrypt of the time. So saying that it "never was acceptable" is simply nonsense.

It was even what was implemented by the standard libraries and APIs of the time.

Re: PHP Commandments

#47

Post by nikic »

> PHP version 5.5 (not yet released) will support Bcrypt natively via its password_hash() function. Use it.

This makes it sound like PHP didn't support bcrypt before 5.5. It did. PHP always has bcrypt support in 5.3 and 5.4. In older versions it also has bcrypt support if the operating system supports it.

PHP 5.5 only added a wrapper around the low-level crypt() API, which makes password hashes more convenient to use and less prone to error.

Re: PHP Commandments

#48

Post by Schlaefer »

TheCapn wrote: post #31
Jleagle wrote: 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…

If you know what you're doing you will not pass around huge arrays (in PHP) by value. Or pass them around (in CakePHP) at all, it's maybe a MVC warning flag that you do something in a place you shouldn't.

Related note: CakePHP 3.0 (current is 2.x) will use objects [1].

[1] https://groups.google.com/d/msg/cake-php/-TLn6RpHt4U/EAP0lt2...

Re: PHP Commandments

#50

Post by UnoriginalGuy »

jcampbell1 wrote: post #44
UnoriginalGuy wrote: post #37

Earlier quoted context omitted.

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 tr…

I am totally confused. Who uses an SMTP server written in PHP? mail() just writes a bit of stuff into a mail queue by default.

People set their PHP config to connect to a remote SMTP server rather than a local queue.

It isn't something you can control in the code.

Post reply on HN