Live data from Hacker News

PHP: The Right Way

phptherightway.com

31–40 of 233 posts

Re: PHP: The Right Way

#31
post #7
post #4

Straight, simple and to the point. Nice. Missing test and QA tools though. Probably an oversight, since the author does suggest following Derick Rethans and Sebastian Bergmann. And another one: read up on the SPL library before you start re-inventing that wheel.

All good points. If you'd like to submit a pull request, I'll be happy to credit you with the additions and get them added to the site.

This is a great idea. Quick grammar correction under Introduction>Input Filtering: remove the apostrophe from "That lead's to dark and dangerous places."

Re: PHP: The Right Way

#32
post #28
post #27

I like the general idea of this, but think that it is nearly useless in its current form. It's way too superficial. To teach newbies how to do things right it doesn't suffice to link to a few resources and hope that they'll read them (hint: they won't). Instead one needs more concrete code examples, etc. Which would obviously be too much for one page :)

I agree. It's very much in a v1.0 form right now. Once I move over to GitHub Pages, I hope to add more links to tutorials and code samples without bloating the document itself.

I think it offers a great starting point, though, and even though I've worked in PHP for a few years, I filled in a couple gaps in my knowledge. Thanks very much.

Re: PHP: The Right Way

#34
The important parts of this eventually come to experienced programmers. I would favour a version of this document that included those with justifications. The less important parts (number-of-spaces-per-indent, somebody's camelCase method preference, etc.) should be pruned. An interesting effort, but really, do we need more 'standards'? Only real way to enforce coding standards: pre-commit hooks on your revision control server. http://xkcd.com/927/

Re: PHP: The Right Way

#35
post #24

Earlier quoted context omitted.

SQL injection attacks alone are almost always a result of not filtering input...

With parametrized queries, that becomes a non-issue, but I still see no point in cluttering the database with data that's just going to be filtered out at some point - might as well filter it before it goes into the DB to begin with. The exception, of course, being those rare cases when some users need to see the filtered data and others need to see the raw data, but even then, you likely won't want to allow everythi…

I am not sure if you are referring to the same sort of filtering mentioned in the document. The data is filtered before it hits the database layer, this saves resource being used.

Re: PHP: The Right Way

#36
post #24

One point in and its already dead wrong, you never filter input, only output. Edit: Everyone talking about databases: paramaterized queries, check them out.

SQL injection attacks alone are almost always a result of not filtering input...

It's sometimes known as sanitising input, so I'm guessing that's what they were trying to refer to.

Re: PHP: The Right Way

#37
post #6

Something to consider mentioning - there are some in PHP these days that take this sort of stuff a bit too far. Drives me nuts to see people writing classes to encapsulate a 3 column database result. So much overhead and boilerplate.

You should check out Java sometime.

Re: PHP: The Right Way

#38
post #14

These guidelines won't save you from some bullshit PHP "rules", such as: http://stackoverflow.com/questions/5810168/php-foreach-by-re...

The result is 100% logical. My own personal guideline is to never use references anywhere; even in a foreach loop you can use the key to modify the original array instead of a reference to the value.

Re: PHP: The Right Way

#39

One point in and its already dead wrong, you never filter input, only output. Edit: Everyone talking about databases: paramaterized queries, check them out.

You've been downvoted but I completely agree. You cannot sanitize text for all possible situations; you can only escape it depending on the output format (database, html, etc).

These functions should be used to "validate" input rather than "filter" it.

Post reply on HN