“PHP: Good Parts”-ish book / reference

Question

Before I had my first proper contact with Javascript I read an excellent book "Javascript: The Good Parts" by Douglas Crockford. I was hoping for something similar in case of PHP. My first thought was this book:

"PHP: The Good Parts" from O'Reilly

However after I read the reviews it seems it totally misses the point. I am looking for a resource that would:

• concentrate on known shortcommings of PHP,
• give concrete examples,
• be as exhaustive as possible

I already see that things can go wrong.

Research: I looked through SO, and Programmers for materials. I obviously found this question:

http://stackoverflow.com/questions/90924/what-is-the-best-php-programming-book

It's general, mine is specific. Moreover I'm reading the top recommendation "PHP Objects, Patterns, and Practice" right now. I find it insufficient -- it doesn't address the bad practices as much as I would like it to.

Motivation: I don't dislike PHP. I'm not even competent enough just yet to really state that. In 3 months however, I will start a job that will likely involve a lot of development in that language. I do not really know what quality the code will be. I also don't want to be the guy to introduce all the bad practices and then learn everything the hard way. I try to find out about as many traps that I possibly can.

In case of Javascript Crockford's lectures really served as a guiding light. I would never feel confident in Javascript without them.

Answer 1

Hmm, the only one I recall off the top of my head is The PHP Anthology by sitepoint. They don't make the best books, but I think this was was decent.

Answer 2

I haven't seen any books, but I'll dare to list things I like about PHP in a shorter format.

First I'll dare to say that PHP is really, really similar to C in its mechanics and philosophy, and if one, like me, tends to prefer C over C++ (or, lol, Java), one might as well find PHP much better than those "better" languages. Some of these points are also valid for Python, Ruby, Lua, etc., but I believe PHP is the best mix.

Second, I'll admit that there are many oh many valid complaints about PHP, but these problems are slowly being phased out. Many "what makes PHP the devil" lists are seriously out of date or filled with subjective crap. Here's my subjective countercrap then.

1. Easy. Yeah, the main reason why PHP is evil is because there's so much bad PHP code out there. But that's not because PHP makes one write bad code, it's because it allows bad code, because it allows any code as long as it is syntactically valid. Just like a scripting language should. The actual effect of that is that good PHP code is generally shorter and more readable. The possibility of writing bad code is a side effect of that. There is a reason so many good projects started with PHP and it's not just popularity.

2. Weak typing. Yes, weak typing often leads to most cryptic bugs if you don't think when you code. If you do, these bugs are very, very rare. On the other hand:

   • Just by removing obligatory int/string conversion the amount of extra code saved is huge. And you can still do it if you really need to be sure.
   • There is some ambiguity with comparison (and it can sometimes bite), but again, if you care, there is always === that works perfectly. In most cases, though, being able to just write if ($anything) is kinda cool.

3. No ambiguity. Weak typing implies having less ambiguity in the language itself. Most of the popular languages have a cute, nice and clean syntax... that leaves you scratching your head on every line, coming back and forward and ctrl-clicking to understand what this cute, clever and maybe even grammatically correct statement actually does. PHP, on the other hand, is quite verbose when it's actually needed.

   • PHP is the only language I can remember where addition and concatenation are actually two different operators.
   • At any point, the scope is always confined to the function/method.
   • The variables always start with a $ - might be ugly, but really helps tell variables from everything else when reading the code.
   • It is also impossible to confuse a local variable and an object field - the latter can be only accessed with $this->.
   • It is even harder to confuse a function call with a method call, or an object call with a static call - again, because all those have different syntax.

4. Dynamicity. PHP isn't too shy to expose all the possibilities of an interpreted language:

   • new $class(), $class::$method(), $function() etc. - comes handy much more often than you would expect.
   • Class autoloading helps to resolve dependencies at the runtime, add class_alias and duck typing and you can have a provider pattern, completely transparent to the actual code. (we use this in our framework)
   • Magic methods offer even more, well, magic possibilities, like adding properties with getters/setters dynamically, once again, transparent to the code. (we use this in our framework too, for ORM).
   • PHP 5.4 adds traits that work more or less like macros, but on a higher level (and at runtime). These too can be autoloaded and aliased.

5. "Arrays".

   • The type called array is actually an all rounder array/hash map/whatever you want it to be.
   • Same syntax for indexed and associative arrays (and in many cases you don't even really care).
   • Being able to easily iterate AND modify a key-value list is another thing much more useful than one might think.
   • An array of mixed types, other arrays and anything else can be used instead of having to define a struct - saves a lot of time. Yes, this is kind of common among dynamic languages, still a valid point.
   • There are real arrays too http://www.php.net/manual/en/spl.datastructures.php

6. Shared-nothing is suddenly viewed by some as a plus. I'd say that threads or at least a decent IPC is #1 on my PHP wishlist, because, yes, I am so crazy as to actually want to use this awful language for non-web tasks. As for the web, well, at least one thing PHP surely makes harder is breaking out of HTTP's statelessness and making a persistent, stateful, unscalable monster. You can still do that if you really, really want to (of course!).

7. Built-in template engine is kinda cool.