JavaScript: The Good Parts is one of my favorite computer books ever written, not just because it’s an excellent primer on JavaScript, but also because the title alone provides guidance to a way of living that’s worth pondering.

This week, PHP: a fractal of bad design is making the rounds. It’s a lengthy list of thoughtful criticism of PHP as a programming language (and Web development platform). The PHP core team should read it, although the truth is that most of the problems can’t be addressed without breaking old PHP applications, and the PHP folks are generally reluctant to make those kinds of changes. PHP has a massive installed base on shared hosting servers — breaking old applications reduces the adoption rate of new versions.

Here’s the deal, though. For all of the complaints about PHP, thousands of businesses rely on it, and millions of people use it with varying degrees of expertise. I personally have spent thousands of hours hacking on PHP applications, sometimes with much frustration. None of the problems listed in that blog post have prevented me from getting my work done in that time.

The secret to using PHP effectively is the same as it is for JavaScript … focus on the good parts. It turns out that works out for most everything in life. When I eat at a restaurant, I don’t have to like everything on the menu, there just has to be one dish that I enjoy. The number of bad dishes on the menu don’t really matter, what counts are the good dishes, at least if you willing to be an educated consumer.

We all choose the set of tradeoffs we’re willing to accept. I’m happy to take advantage of the opportunities working with PHP provides and do my best to stick to the good parts.

Fairly often I find myself writing complex boolean expressions. For example, let’s say I’m writing a function in a controller that renders a page, and I want to check whether the current user is authorized to view that page. Here’s some code:

if ((!($a || $b)) && $c != $d) || !$e) {
    // Do something.
}

Aside from the variable names, that’s real code. There are two things about that code that to me greatly hinder readability. I rewrote it as essentially the following:

if ($x != $y || !$z || !$w) {
    // Do something.
}

The second code has two advantages. First, no internal parentheses are needed, and second, there’s no mixture of “and” and “or”. Whenever I can, I like to use only one boolean operator in a complex boolean expression, because sorting out different operators can be confusing. In the second example, I know that if any of the expressions evaluates as true, then the code in the block will be invoked. When you mix operators, things aren’t so straightforward. And not requiring parentheses is related. When you mix operators, precedence comes into play, and you can use parentheses to manage precedence. So as soon as you bring either of them to the party, you can no longer read your expressions from right to left.

This just occurred to me so there’s probably something I’m missing, but for the time being, I’m going to try to be disciplined about sticking to one boolean operator at a time in cases like this. (And yes, I’m not counting the “nots”.)