This is not a surprising ranking. After all, Tim is from Sun, and the maintainability complaint is common in Anti-PHP rants. I’m not trying to suggest that Tim is anti-PHP, far from it, it seems. I’m just using his ranking as a spring board to ask questions.

Chances are that your average Java jockey or C scientist’s first exposure to PHP is to download one of the popular PHP applications. These are usually the product of some open source mega-project with developers of varying degrees of skill. Our engineer-by-day spends a few evenings with the program. The code is not technically outstanding.

How can something like this be so popular he asks? Yet, the software is successful by definition. Nobody downloads unsuccessful open source applications. The technocrat, heavily invested in his own technical prowess, faced with successful yet technically inferior code experiences cognitive dissonance. The only thing to do is to belittle the successful, but surely offensive code. “I could write better code than this,” he says, or “this code sucks,” or “this is unmaintainable.”

It is easy to dismiss these gripes inside the PHP community. After all, those of us using PHP professionally can write maintainable code in PHP. Ask any programmer and they will tell you, “My code is maintainable.” Who writes all of this unmaintainable code, anyway?

Lets take this gripe at face value for a moment. Why is PHP code considered hard to maintain? Is it the language that produces code that is hard to maintain, or is it that the popular ambassadors of the language happen to be programs that are hard to maintain?

Another common PHP sucks complaint is that PHP doesn’t scale. When you are talking about traffic, there are all sorts of counter examples for this. Personally, I’m dying to learn the story behind those .php extensions on YouTube. But, this post is not about requests per second.

Another kind of scalability is team size. I think that when some people complain that PHP doesn’t scale, what they mean is that PHP doesn’t scale to large development teams or large projects. Now we are back to the maintainability issue.

What is it about PHP that makes people think that it is not suitable for larger development teams?

The criticisms of maintainability and scalability generally come from outside the PHP community. But, there is a common complaint from within the PHP community.

It is hard to find a PHP wish list that doesn’t include namespaces. It comes up again and again.

Sometimes users request a feature without explicitly making their true desires and intentions known. They say “I want feature X,” but what they really mean is “solve problem Y.” Good programmers can hear the request for X, but make the jump to solving Y.

When people ask for the namespace feature, the problem they want to solve is integrating code from multiple parties. I wonder if the frequency of this request is a signal of a problem in this department? Perhaps one that requires more than just namespaces to solve? Is the namespace request a proxy for a larger problem?

What is it about PHP that makes it hard to integrate code written by multiple parties, whether they be different developers or different organizations?

A little History … (lest we forget)

Gotos have had a long and sordid history in computer science. In the early days, before languages had a rich set of control structures, goto’s were it. It turned out that overusing GOTOs made the control flow of programs hard to follow and thus programs difficult to maintain. Dijkstra’s 1968 paper Go To Statement Considered Harmful is considered a classic for recognizing this fact. GOTO enriched programs are sometimes called Spaghetti Code

A movement was spawned to eschew the GOTO with as much zealotry as todays modern Object Oriented fanatic uses to eschew “procedural code.” This movement was called Structured Programming. The central premise being that any given block of code should have one entry point and one exit point. Presto … control flow is now easy to understand.

And so the structured programmers waged war on low level control structures in favor of high level control structures. And you know what? They won. Languages were constructed without GOTO statements. Computer science degrees became harder to get for those with an affinity to goto. Higher level control structures flourished.

As some of the zealotry faded, it turned out that sometimes multiple exit points can be useful for clarifying code. Continue, return, and break and later throw all provide ways to provide multiple exit points to a block of code.

Multiple entry points remain blissfully rare except for the occasional confusing fall-through case in a switch statement.

Early in my career, I had the (mis)fortune to be a maintenance programmer on some older programs written in the unstructured style with gotos. This is where I learned debugging, code smells and refactoring. Not having a source code control system, the programmer before me was loathe to actually remove unused code from a program, so he would simply GOTO around it. After years of this, a program might be 50% dead code. Goto “patches” were used instead of subroutines. A goto would jump to a distant location, perform some operations, and then jump back. FOR loops were simulated with gotos. Living with wholesale GOTO abuse, like some sort of war atrocity is not easily forgotten.

GOTOs in PHP

What surprised me most about the GOTO patch for PHP is the positive reception that it has received. There seem to be three arguemnts in favor of it:

1. it is useful for error handling.
2. it is useful for writing parsers
3. it can be faster than other control structures

Regarding error handling, I think that using GOTO for error handling is like simulating for loops with GOTO. Why use the low level concept, when the higher level concept works better? try..catch and try..finally are designed for error handling. Use them.

Would people try to simulate gotos with exceptions? Perhaps. While that might be bad, gotos might be worse. The big difference is that exceptions can only provide multiple points of exit from a block of code. Gotos can provide multiple points of entry. Goto is far easier to abuse than exceptions.

Another difference between gotos and exceptions is that gotos in PHP are limited to a single scope, while exceptions can cross scope. This is important when a low level function may know that an error has occurred, but not what to do about it.

Using gotos for error handling increases the active area of variables involved in the error from the point of error occurrence to the point of error handling. This is bad and not just for compiler register allocation algorithms.

I think that people who want to use goto for error handling probably don’t understand how to use exceptions properly yet. (Thinking in C?)

Gotos are handy for parsing? Yes, but they are usually used in generated code built by lex or yacc. This is code not meant to be maintained by humans. If you are hand constructing a parser, you probably aren’t going to use tight state transition loops as generated by these programs. It is possible to write a reasonably fast parser in PHP without goto.

Goto is faster? This is related to parsing. The cost of parsing in PHP is allocating memory for substrings, anyway. This will probably dwarf any gains in control flow. If you sacrifice maintainability for speed at the micro level, you obfuscate opportunities for real performance gains, which almost always occur at the macro level. Don’t sacrifice speed for maintainability.

Having a goto statement makes control flow analysis more difficult for any current or future optimizing compilers. What is confusing for people turns out to be confusing for computers as well.

Java provides a little used labeled statement which can be the target of a break or continue statement. This allows escaping deep nesting (a bad code smell on its own) without introducing the problems of multiple points of entry. This might be a better alternative.

Not once in four years of programming in PHP have I thought to myself “I wish PHP had a goto statement.”

Perhaps worst of all, I think having goto will cause serious programmers to take PHP less seriously as a language.