Mindblind

We’ve established already that PHP sucks. Now, there’s still lots of reasons you might find yourself developing a web app in PHP: you have a project that needs doing and you know PHP already, or more likely your client or employer demands it. I know, you’d probably rather be developing in Python or Rails or almost anything else, but don’t worry. PHP’s still going to suck, but there’s plenty you can do to make the suicidal tendencies less intense.

I’ve mentioned phpSprockets already — you did read the post and watch the screencast, right? — and that’s an excellent first step. But that won’t get you very far. You’re still stuck in a land of writing a bunch mysql_connect() and include 'header.php' lines at the top of every file, right?

Hell no, this isn’t 1997!

Read the rest of this entry »

EDIT (5 Feb 2008): As indicated in the comments below, some of my reasoning here isn’t completely accurate. Apparently Windows Forms runs under Mono now, albeit not some of the newest stuff. A lot of people seem to be angry at the “Watch your backs, it’s Microsoft and they might sue” thing — I think it’s definitely something to keep in mind if you’re making a living doing Mono development but probably not too much to worry about for anything else.

So, Eddie at Innova has been touting the awesomeness of C# and the Common Language Runtime for a while — how it’s so awesome that he can write code under Mono and run it under Windows using Microsoft’s .NET runtime. And, he can take advantage of all of the .NET libraries! And if C# is the problem (which he explains is a fantastic language) then why not use IronPython or IronRuby or some such?

On the surface, this sounds like the panacea the industry’s been looking for since Sun adopted the “Write Once, Run Anywhere” slogan for Java. Certainly seems enticing — writing in whatever language you want from the set of languages that can compile down to IL, running on any platform that’s got a compatible runtime.

Except I just don’t like it.

Read the rest of this entry »

Kids: there is indeed a reason that people tell you to comment your code:

…today I uncovered a long forgotten beloved project of mine, and I dove in to get it into some kind of working shape, now that I had the experience to actually do it right. Of course, there were no comments anywhere, and there were some mysterious things going on, so it took me a while to figure out what it was all about. But this time, every time I figured something out about the old piece of code I put a comment there, explaining what it was all about. By the time I was happily hacking away at it, I realized this was the best documented piece of code I had ever written

This is an excellent way to get your code documented, and I’ve had to do this a few times myself. But imagine if you didn’t write the code in question, and you had to pick up someone else’s project from six months ago? Now the original author’s forgot all about it, and you have to figure everything out on your own.

Commenting your code beforehand saves time, energy, and lives. Leaving it until later is almost a guarantee it won’t get done. But poor commenting can make a file unreadable. Here’s a few good rules:

1. Do comment particularly tricky blocks or lines of code. Anything that’s likely to trip up someone reading the code in a few months. If you’re having trouble, check for these problem areas:
   • regular expressions
   • ternary operations (x = (expr) ? true : false)
   • bit twiddling
   • global variables
2. Do comment variables that aren’t defined in the current scope. PHP with register_globals on practically demands it. (Or, y’know, just turn it off.) Global variables, or variables that are unexpectedly modified inside subroutines, are also good areas.
3. Do keep the comments short and to the point. For example, nobody needs an introduction to finite state machines or role-based ACLs in the middle of the code.
4. Do update the comments when the code changes. If you’re following the previous rule and keeping things short and succinct this isn’t as much of a chore.
5. Don’t comment the obvious. Flooding the file with comments like # declaring age as an int or // incrementing loop variable actually have the reverse effect and make the code extremely difficult to read. If the code doesn’t need commenting don’t force it.

For the sake of your fellow coders, or your sanity when maintenance time comes, take a few seconds to put a quick # This regex validates a phone number in the format (xxx) xxx-xxxx, with or without the parenthesis.

I am so tired of people defending PHP.

Note: this is good natured. The guy that wrote the original article — why can I never find names on these things? — makes a few good points. And, for full disclosure, I work with PHP full-time right now, and it’s still my go-to language for knocking out a web application because I’m so familiar with it. (And even then, only with Zend Framework and phpSprockets.)

But seriously, PHP is sickening. I’ve started using Ruby and Python for any tasks I can get away with and they’re really worlds apart. PHP’s got some good in it but it’s all buried under deep layers of hate. That’s right, PHP hates you.

PHP is terrible

Need proof? Here it is, broken down by category:

Language Features

• So many things evaluate to boolean false or boolean true that there had to be a new operator introduced (=== and !==) to do strict comparisons.
• You can’t differentiate between a hash or a list or anything. They’re all the same. Even if you know you’ll never need a keyed index, you can’t turn it off.
• It’s Object Orientation is broken in places (late static binding).
• It doesn’t support lambas. create_function() is not a lambda.
• You never know if short_open_tags is on, or if safe_mode is on, or if (ugh) register_globals is on.

Built-in Functionalty

• It comes with a standard library that has no naming convention. You never know in what order the words will come in or if they’re separated by underscores or not:
  • str_replace()
  • strlen()
  • parse_str()
• You never know what order the arguments are in:
  • in_array($needle, $haystack)
  • strpos($haystack, $needle)
  • You constantly have to check your output thanks to type restrictions:
  • strpos(’abcd’, ‘a’) will return 0. Don’t test this with if (strpos(’abcd’, ‘a’)) { … } because 0 is secretly false! You’ve got to use if (strpos(’abcd’, ‘a’) !== false).

Common use

A lot of open source projects are written in it, such as Joomla, Wordpress, and MediaWiki. All of their code is hideous, and half of the time there’s random HTML in the middle of their scripts because, of course, we’re working with webpages and why would you ever want to abstract the output from the logic?

Irrelevant praise

Here are some common praises of PHP and why they don’t matter:

PHP is great because it allows the new user to pick it up quickly!

Sure. And if the introductory material available covered good programming style we might not have a problem. In reality, every example PHP script is riddled with SQL Injection vulnerabilities, XSS vulnerabilities, and terrible programming. Most newbs never learn a better way of doing things because this gets them results that look good very quickly.

PHP has classes, it doesn’t need namespaces.

Fail. Use a language with namespaces for a few months and come back to PHP. I did. It’s sickening.

Globals are okay!

Whoever taught you that needs to be shot. Globals are not okay. They are tolerable in certain situations, but if you make blanket statements like “Globals pierce through all the layers of code and get right to the heart of the matter.” then you’re clearly using them too much.

I thought I’d come out with the big guns for our inaugural post. If you’ve ever written a PHP-powered site, you’ll know that the mix of PHP and HTML in the same document can quickly become hideous to read and a nightmare to maintain.

The usual solution is o use a template engine like Smarty, but these are hard to learn and are overkill for smaller projects.

What’s a developer to do?

Read the rest of this entry »