Unusually for me, I did not speak on a Zend Framework topic, and had only one regular slot (I also co-presented a Design Patterns tutorial with my team). That slot, however, became one of my favorite talks I've delivered: "Designing Beautiful Software". I've given this talk a couple times before, but I completely rewrote it for this conference in order to better convey my core message: beautiful software is maintainable and extensible; writing software is a craft.

You can find the slides for his presentation on his site as well.

Hacking is an art, and hackers should act as artists. Hackers and painters have a lot in common but I won't talk about the analogy too much as Paul Graham wrote an excellent essay and a whole book on this topic. I recommend you to read both of them if you are a hacker or a developer.

He points out that "beautiful code" is a good thing - unfortunately developers for companies may not have the luxury of writing it. He does suggest hacking on your own time, though. Not only is it good for you, getting out those ideas into working code, but it can also positively effect the applications you develop at your work.

I got some interesting comments to my previous post on "beautiful code". Some were pretty strong disagreements. So am I wrong? Did I get carried away? Did my critical faculty go on vacation somewhere nice and sunny? [...] My main point is that it's close to plain English. Not everyone agrees that that's a good thing, but I argue that we're built (genetically wired, in fact) to understand natural languages, not program code.

He reasons that code should be easier to understand than just a bunch of random functions and parameters jumbled together. He thinks that it should read more like a human could understand rather than just the machine. With function names like "assertThat" and "hasSelect", it does make it easier to follow.

What is beautiful code? Ask ten people, and you will probably get ten different answers. Ask them what makes a programming language beautiful, and you've got yourself the beginnings of a holy war.

He compares code to art - the language is just a tool, the canvas an editor waiting to be filled with lines of artist-generated works. Because of PHP's wonderful flexibility, it can be molded to fit just about any need a coder might see fit and gives them the power they need to really dig into the code and about the "paint by numbers" sort fo things language like Ruby have to offer.

Now I've written actions like the one above in the past as well. It's just that I've not had many MySql errors since I've switched to CakePHP. The Model class usually handles all the DB operations flawlessly and it's probably been over a year that I've written a custom MySql statement in my code somewhere. However, even CakePHP or, what's more likely, the database can fail or deny operations.

He shows some code snippets of what he sees as less beautiful versions of database insertion code, methods that either don't check the response/errors or make a messy job of it. His solution works by returning the result into a switch statement to check the results and handling it there (versus a series of ifs). There's a class you'll need to make it work (Common), but he shows how to use it and creates a simple "add" example with it and a new Controller to handle the request.

Cal also includes some of the reasons the PHPFormatter crew give for making code beautiful, including bringing a project's code up to your current style or fixing a downloaded, unreadable script. You can also use it to format your code to fit with the PEAR style.