PHP Pitfalls

by Udo • 14 years ago

24 41 14 years ago

sedev• 14 years ago

Life is too short to read another half-hearted defense of a terrible language. This author lost me when he started out by only acknowledging the critiques of PHP that he could handwave away. If he actually had a coherent response to "Fractal Of Bad Design," that would be something worth reading on its own.

To the author: doesn't the fact that you have to point out all of these things to avoid say something to you about core issues with the language?

Udo6• 14 years ago

No. Fact is, the language is used by a lot of people who have no clue what they're doing. This article is not for them. Come to think of it, it's not for you either. It's for people who use PHP with some degree of competence.

I think PHP is to a large degree a victim of its own success. The runtime's ubiquity means that a lot of very incompetent people are fiddling around with things they don't understand. If you look at, say, PHP-related questions on Stack Overflow, you'll notice they are of extremely low quality that have nothing to do with PHP itself, but have everything to do with the person behind them not understanding the simplest things about programming.

ericcholis• 14 years ago

Simply put, the strength of PHP is also it's greatest failure. It's got a very low barrier for entry, but a very high learning curve for doing things correctly (efficiently, securely, etc...).

I know I've fallen into many of the traditional PHP traps simply due to what I call language laziness. "Why do it this way when the other way is so much faster". PHP allows you to do quite a few things wrong very quickly.

I'm a closet PHP fan, but not compared to "better" languages like Python.

k3n2• 14 years ago

Only 1 paragraph deals with PHP's reputation, the rest is geared towards those who actually want to learn PHP and/or improve their skills.

To you: doesn't the fact that you myopically dismissed the entire article due to a single paragraph say something about you? Why are you looking for a flamewar where one doesn't exist?

I get it -- you don't like PHP. That's your prerogative, and you're of course entitled to it, but this article isn't just another skirmishing ground for the flamewar that is "PHP SUCKS" vs. "NO IT DOESN'T". Rather, it looks to me to be more of a braindump from a PHP dev looking to enlighten new PHP devs with what he's learned.

Is that so patently offensive to you that you have to attempt and interject the played-out flamewar that is now a decade old?

drzaiusapelord• 14 years ago

>Only 1 paragraph deals with PHP's reputation, the rest is geared towards those who actually want to learn PHP and/or improve their skills.

Do we really expect the language elitists to actually read articles now? Just say something bad about PHP here and you'll get 20 instant upvotes. We're getting as bad as reddit here.

As someone who uses PHP, I found this article very enlightening.

ohwp2• 14 years ago

To your half-hearted comment: show me a language where an unexperienced programmer can't create security issues, bugs, memory leaks and so on.

The author is just giving some good advice to PHP programmers. If you don't like it, just don't read it.

jasonlotito• 14 years ago

> a coherent response to "Fractal Of Bad Design,"

There have been numerous responses already that debunk many of the claims presented there. Suffice it to say, you came to this with your mind already made, and nothing is going to change it.

So, why bother?

jrogers65• 14 years ago

I agree that the vast majority of PHP code is terrible and that the language itself is full of annoying flaws but take a look at Symfony 2 if you care to. It's a well architectured framework which uses best practices borrowed from other languages/frameworks and ends up as something coherent, well designed, reliable and a pleasure to work with.

smacktoward• 14 years ago

Avoid making a database connection when your request doesn’t need it. And when your request does need it, you should prefer mysql_pconnect() over mysql_connect() for the simple reason that it potentially shaves some execution time off the connection part.

Actually you should avoid using both mysql_pconnect and mysql_connect, because they're both functions from the deprecated old mysql library of database functions. The preferred way to deal with MySQL databases in 2012 is to use either PDO (http://php.net/manual/en/book.pdo.php) or the "improved MySQL" library (http://php.net/manual/en/book.mysqli.php), both of which are better architected and give you access to things like prepared statements that the old mysql library does not.

There's really no good reason to be using the old mysql library at this point. Unfortunately, however, there's a vast amount of ancient PHP tutorials, code snippets, and other copypasta floating around out there that uses it, so people who don't know better still pick it up.

Udo6• 14 years ago

That's absolutely true, but I was using the generic MySQL lib as a kind of common-ground illustration. The actual point translates just as well to any other DB library. Establishing a connection to the server and issuing queries takes a lot of time and often times it's done for all requests even if some of them don't need fresh DB data.

numbsafari2• 14 years ago

Yeah, except you're talking about PHP Pitfalls and failed to mention and then fell victim to and perpetuated the #1 Pitfall of PHP: Legacy Cruft.

PHP's libraries are full of Legacy Cruft that any other sane system would have deprecated and eliminated during a major revision transition.

The wholly inefficient and unsafe legacy MySQL lib is one of the primary examples.

Good on you for at least mentioning parameterized statements, but you didn't really follow through. You then go on to confuse the situation by talking about the old API.

Instead, you should have just said "Using this old API is a horrible idea. Don't. Ignore every guide or tutorial that does."

PHP has evolved considerably from its roots. The #1 problem with PHP is that it still lives in its parent's basement and hangs out with the same losers it met in Kindergarten.

eperoumal• 14 years ago

Bound parameters with prepared statements is the winning combination in any programming language.

vegas• 14 years ago

PHP Pitfalls: PHP :D

fyolnish• 14 years ago

You don’t even need serverside debuggers or fancy instrumentation to achieve this. The function microtime() returns a timestamp in microseconds. This makes it easy for you to check the passage of time at key points during your application’s execution path.

Yes, that's just as good as a real profiler.

Udo6• 14 years ago

Obviously I'm not saying that, but it's a reasonably good method of determining how certain parts of your code perform.

debacle4• 14 years ago

Very long, and I don't think the prose style fits the information you're trying to deliver.

It's a pretty good attempt, though. I would have liked to see more links for more information, and you don't mention packagist at all.

Either way, a good start. Knowing about these ideas, and knowing why to care about them, is the first step to becoming a better programmer, regardless of the language.

Udo6• 14 years ago

That's a nice way of saying my writing style sucks, but it's still a welcome (and probably appropriate) critique. I'm open to suggestions on improvements.

It's true that I didn't include a lot of links to more advanced frameworks and libraries, mainly because I wanted to limit the scope of the article to the basics of the PHP runtime. I also think that in order to avoid mistakes people should think more about those basics, even when they happen inside convenient library methods.

If you think there are links to essentials that should be in there, you're welcome to contribute them in the comments.

debacle4• 14 years ago

Packagist is important because if you don't mention it they're going to use PEAR or PECL or (gasp) Zend Framework, all of which are generally inferior to what is offered on Packagist.

kokey• 14 years ago

I liked your writing style, it actually kept me engaged until the end. I guess it also helped that I had an interest since I'll be supporting php applications for the first time in 5 years.

quadyeast• 14 years ago

Writing style does not suck. Thanks for the timely tips. Just applied htmlspecialchars.

ohwp2• 14 years ago

For debugging, profiling and optimizing Xdebug is highly recommend: http://xdebug.org/

Udo6• 14 years ago

Good point, I appended that link to the profiling section.

I noticed there is some discontent with my use of the microtime() method. It's not intended to replace a serious debugger/profiler, but it is something that's available in any PHP environment for quick performance checks.

madaxe• 14 years ago

Profiling with microtime? What's wrong with XHProf?

insulanus• 14 years ago

I decided to stop reading after the phrase " The blame lies solely with the developers using it".

greyfade• 14 years ago

He makes some useful observations and good points after that.

But most of what he says is on my "List of Reasons to Never Use PHP Ever Again."

sandfox• 14 years ago

HA - pitfalls include needlessly using low level functionality when any number of hundreds of higher level (to varying degrees) frameworks and libraries that would abstract away most of these problems, and easily installed/found with composer/packagist. Why most PHP'ers ever need to write a mysql(i)_* function is beyond me. There are plenty of perfectly good wheels out there and you're not re-inventing a better on.

rb12345• 14 years ago

That's assuming that the users have the server access to install the packages or an up-to-date PHP interpreter. A lot of the appeal of PHP is that it is available on cheap shared hosting, which until recently would not be guaranteed to have PDO, mysqli and friends installed. If you have access to a VPS of some sort, you can easily install such things, but in that case you can also use a different language.

TazeTSchnitzel3• 14 years ago

Here's a pitfall I know from briefly trying to improve PHP, and having developed in it:

The syntax definition is used for some types of basic type-checking.

I'm completely serious.

Because of this, if you try to do a combination of property/array/etc. accesses that the grammar designers didn't envision, you'll get a very cryptic error. For example, this (which runs an anonymous function dereferenced from an array dereferencing from a static member of a class):

  self::$views[$path]();

Doesn't work. It assumes that the result of self::$views[$path] is a string, and then complains there is no function with that name. (Yes, you can execute strings with names of functions, as if they were that function...) But this:

  $x = self::$views[$path];
  $x();

Does work.

Please, don't use PHP. It's horrible.

lutusp• 14 years ago

> Please, don't use PHP. It's horrible.

I wish I could upvote this comment a dozen times, for a combination of candor and useful fact.

meaty• 14 years ago

Instantly invoking Godwin's law; knowing about the Nazis causes a moral shift towards making sure some horrible things don't happen again.

The same applies to PHP. please do use it for a bit, learn about the crimes and don't repeat them :)

k3n2• 14 years ago

Because all other languages are without problems.

TazeTSchnitzel3• 14 years ago

PHP has more than its fair share.

PHP Pitfalls

Related Stories