One of the nice things about iterators is the ability to shove them into other iterators, allowing you to wrap their functionality in other functionality to return a more precise result set. Take for example the idea that we want to read a directory to list only the images inside of it. There are two main ways to do this, via readdir functions and via FilesystemIterator objects. Going the FilesystemIterator route, one common way seems to be extend another class called FilterIterator which allows you to customize a filter based on you overwriting a method called accept().

He shows not only overriding the "accept" method, but also the constructor to make using this new iterator a much simpler (and cleaner) call. You can find out more about the FilesystemIterator (and others) over in the Iterators section of the PHP manual.

Unfortunately the first reaction to a poorly written application is usually a resounding "rewrite". Developers feel like a weight is lifted from their shoulders, as the manager hears a distant "cha-ching" sounds of money slipping away. [...] In the managers mind a rewrite means it must all be duplicated, and that's not far from the truth when we consider the salaries of an entire development team for the time it will take to rewrite the entire application.

Adam talks about some of his experience in the past with challenging applications and a typical scenario where one group in the company splits off and creates the new version while another maintains the old. He suggests, however, that refactoring may be a more viable option. While it might not seem easier to handle overall, the end results could lead to a more stable system and could take less time than starting from scratch.

Adam Culp posted the 3rd article in his Clean Development Series this week, Dirty Code (how to spot/smell it). When you read it, you should keep in mind that he is pointing out practices which correlate with poorly written code not prescribing a list of things to avoid. It's a good list of things to look for and engendered quite a discussion in our internal Musketeers IRC.

His suggestions include things like "Comments are valuable", "Using switch statements" and a few other smaller ones involving error suppression, globals and prepared statements in database usage.

Whether we're experienced developers or newcomers, we've all seen code that could/should have been done better. Many times it's even code we ourselves wrote and revisited later for one reason or another. I, for one, have seen my share of code written by a "past me" and wondered what on earth I was thinking when I wrote that. Of course there has also been times when I was hired to fix another developers code, and it can be scary also.

There's three posts in the series:

• Part 1, Dirty Code (cause/effect)
• Part 2, Dirty Code (why we do it)
• Part 3, Dirty Code (how to spot/smell it)

"Laravel is a clean and classy framework for PHP web development. Freeing you from spaghetti code, Laravel helps you create wonderful applications using simple, expressive syntax. Development should be a creative experience that you enjoy, not something that is painful. Enjoy the fresh air." That's the text which can be found on the Laravel homepage and, if we'd believe it, wouldn't it be wonderful? Let's test this claim by building a simple TODO application and see how much effort we have to put into it.

The article is pretty high-level and only touches on some of the key features like migrations (to create the database) and making the controller, model and view for the basic TODO app.

Even bad code can function. But if code isn't clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn't have to be that way. In this session you will learn how you can offset your technical debt with clean code that is readable and testable as well as reusable.

You can listen to this latest session either using the in-page player or by downloading the mp3 directly. The slides (for a similar version of the presentation) can be found on Slideshare.

"The Art of Readable Code" was written by Dustin Bowell and Trevor Foucher and basically focuses on concepts and suggestions to make you code not just readable, but comprehendible by other developers, or as the author's suggest, yourself in six months. Code readability is a topic that I truly believe the PHP community does not focus enough on and i really wanted a look at this book to see what kind of ideas it had and what I could do my best to bring to the attention of other developers.

The book is language-agnostic and provides ideas that developers should keep in mind when doing their development - clear variable names, making comments that make sense, refactoring tips and hints for implementing your ideas in code. He recommends the book to any developer (in any language) to help them make code that will stand the test of time and be easier to manage/understand in the future.

After seven release candidates, it's clear PHP 5.4 is coming: as always the improvements from the previous minor version are many. [...] Let's look at the new features and score them on two metrics: usefulness, and potential for abuse. I'll try to avoid discussing non-language related matters.

He starts by pointing out some of the "gotchas" that can happen with traits (like errors thrown when more than one method is named the same and that they are a separate hierarchy), the short syntax and dereferencing support for arrays, closure binding, upload progress and more. For each of them he gives two measurements - the usefulness of the feature and the potential for abuse.

The essence of pretty code is that one can infer much about the code's structure from a glance, without completely reading it. I call this "visual parsing": discerning the flow and relative importance of code from its shape. Engineering such code requires a certain amount of artifice to transform otherwise working code into working, readable code, making the extra step to leave visual cues for the user, not the compiler.

The goal of these recommendations isn't to help you structure your code better or to optimize it for the best performance. The goal is to make code that is easy to follow and simpler to read for both the experienced developers and those just coming in.

Their suggestions include making the code blend in, keeping the code "untangled", including plenty of comments and reducing clutter overall.

Usability guidelines can sometimes be of use in awkward places. I try to apply them to source code. [...] Of course, coding guidelines are there to make the code easy to read by everyone. But code usability goes somehow beyond. Let's see some of the differences.

He compares good versus bad code in a few different areas:

• Bad Code Comments
• Split Up Code
• Cleanliness
• New Conventions
• Listen To User Feedback

Each item is described, some including code examples to help make them more clear. Be sure to check out the comments for more good suggestions.