Earlier quoted context omitted.
I'm just upset that you don't have braces around the inner body of your `for` statements. I want to edit the DOM just to fix it.
His indent level is set enough that it's likely not an issue. (Yes, the "what if you add another statement line later?!" trope has been registered.)
PHP: The Right Way
191–200 of 233 posts
Re: PHP: The Right Way
#192One 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...
Re: PHP: The Right Way
#193Earlier quoted context omitted.
You are completely correct - you are being unfairly prejudiced by judging PHP on explanations of people that do not understand it instead of learning it. If you learned it, you would know references work exactly like they supposed to, and do exactly what they are meant to do - just because they are not, as parent assumes, pointers, he misunderstands them and thinks they are weird. Moreover, he thinks since PHP in not…
I think the whole point here is why does PHP even have references like that. Right now the only mainstream language I know that does that is C++ and well, its C++ and mutable references are actually not frequently used in practice. Most other languages stay with pass by value most of the time and PHP references kind of look like a leaky abstraction from the underlying C implementation...
(Well, ignoring operator overloading anyway… you could conceivably import PHP's concept of variables and references into C++.)
Re: PHP: The Right Way
#194Earlier quoted context omitted.
Im sorry but accepting underscores as a valid alternative to namespaces in 2012, is not a "best practice". The whole concept of PSR-0 is ridiculous anyway, because PHP supports registering multiple class loaders. If a project wants to use a naming convention that won't work with standard spl_autoload(), they can register their own autoloader.
except if you've ever had to work with lots of different autoloaders at once you'll know that you regularly get conflicts, and getting the correct autoloader order is often a case of trial and error. Using sane conventions across libraries avoids all of this mess.
The built-in spl_autoload offers better support for modern code than the PSR-0 recommended autoloader
Re: PHP: The Right Way
#195Earlier quoted context omitted.
That quip would also be an argument against error-correcting codes. Whatever I think of PHP I'm not gonna look to Confucius for engineering advice. (Now Laozi on the other hand... :)
As far as arguments about ECC, I always enjoyed the parody of a saying attributed to JWZ: 'Someone has a problem and they think, I know, I'll use error-correcting codes! Now they either have 0 or 2 problems.'
Re: PHP: The Right Way
#196That being said... Every language has its strengths and weaknesses. There is nothing fundamentally wrong with PHP (except maybe that if you look at it it's not a very exciting language, even a bit boring). Security for instance has nothing to do with the language itself. And as for PHP syntax, it's a blessing compared to some other languages; at least we don't have a semicolon debate in PHP land ;-)
Re: PHP: The Right Way
#197Earlier quoted context omitted.
You should check out Java sometime.
The problem is not Java, but some types of architects that flourish in corporations, usually doing designs with endless numbers of abstractions, layer upon layer. I've seen this happening in C, followed by C++, and now Java and C#. They will do it regardless of the language being used.
Java itself can be a beautifully terse language.
Re: PHP: The Right Way
#198As a part-time PHP hater who often has to work with it professionally, I believe this is a fantastic resource. The bit on databases in particular is something that all PHP devs should read. That said, it is difficult to bring a legacy code base in line with modern style, though you can improve it over time. Also, this could benefit from some other gotchas, extremely surprising behavior and best practices for avoiding…
On a database section, I am not a fan of PDO and I choose native interfaces like mysqli for my DAO layer or opt for something high level like ORM depending on the requirements. But it goes without saying that protection from SQL injection is a must, it is just PDO's statement binding is not the only way. MySQLi does support data binding, and for others it is easy to DIY using sprintf and whatever is the escaping meth…
Re: PHP: The Right Way
#199Earlier quoted context omitted.
except if you've ever had to work with lots of different autoloaders at once you'll know that you regularly get conflicts, and getting the correct autoloader order is often a case of trial and error. Using sane conventions across libraries avoids all of this mess.
i wouldn't call using underscores for namespaces and forced filenames "sane". The built-in spl_autoload offers better support for modern code than the PSR-0 recommended autoloader
Re: PHP: The Right Way
#200Right way to write PHP indeed. Sometimes I wish PHP itself was written this way. Oh! The guide does not mention the case: if a class contains only one static method, please, use a function. It does not look as educated, but it's obviously a function. Not PHP specific, I admit.
Oh god yes. I ran into an extreme case of this recently. 200 something lines of class definition, class variables and internal private methods that end up chaining 5-deep, with a single public method. Refactoring to a single function took it down to under 20 lines. I wish I knew what motivated people to do things like this.
Hell, I even went there myself at one point, at first doing it to DRY up a bunch of procedural scripts, but later introducing more abstractions to bend the existing code to my will.
Now, I prefer simplicity and will often scrap code that jumps through all sorts of hoops just to do something simple.