

PHP Pitfalls - Udo
http://creativepark.net/1439

======
smacktoward
_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.

~~~
Udo
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.

~~~
numbsafari
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.

~~~
valuegram
Couldn't this be seen as a "benefit" - not having to rewrite code after every
major release?

~~~
TazeTSchnitzel
You still do. They do break things with each major release, sometimes in a big
way. (Fatal-by-default errors for some types of "bad" OOP code and not setting
the timezone in PHP 5.4, for example). Just not as much as some other
languages.

------
TazeTSchnitzel
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.

~~~
k3n
Because all other languages are without problems.

~~~
TazeTSchnitzel
PHP has more than its fair share.

------
sedev
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?

~~~
k3n
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
>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.

------
fyolnish
_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.

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

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

~~~
Udo
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.

------
debacle
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.

~~~
Udo
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.

~~~
kokey
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.

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

~~~
greyfade
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
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
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.

------
vegas
PHP Pitfalls: PHP :D

------
madaxe
Profiling with microtime? What's wrong with XHProf?

