Matthew Weier O'Phinny has a new post to his site today sharing the video and slides from his "Beautiful Code" talk from this year's ZendCon conference.

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.

Fabien Potencier has a suggestion for developers out there - don't just look at what you write as something functional that just does a job, be an artist!

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.

Continuing on from a previous post, the PHP in Action blog takes another look at their suggestions on "beautiful code" with some responses to the previous post.

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.

In this new post to his blog Marco Tabini eloquently explains something that less and less seem to be able to understand - the tool is only a means to an end. It's more about the artist and the end result than the tool.

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.

In a new post to his blog today, Felix Geisendorfer shares a method to make error handling in the CakePHP model functionality a bit more "beautiful".

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.

In a new post to his blog today, Felix Geisendorfer shares a method to make error handling in the CakePHP model functionality a bit more "beautiful".

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.

In this post from the Zend Developer Network, there's some talk about a web service that can be useful to any PHP developer out there - new to the language or not. Bad coding practices can lead to hard to read code, the worst of them is not formating your code correctly. Thankfully, there's PHPFormatter to help out.

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.

In this post from the Zend Developer Network, there's some talk about a web service that can be useful to any PHP developer out there - new to the language or not. Bad coding practices can lead to hard to read code, the worst of them is not formating your code correctly. Thankfully, there's PHPFormatter to help out.

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.