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)

We've all come across code that's written so craftily that it takes us some time to figure out what's actually going on in that block of code. We've never written things like that ourselves of course....seriously though, if you're collaborating, not doing things in the simplest terms will create an issue when other people start to look at your code. There is something about us; when we have an opportunity to show off how smart we are; we really try to go for it. The point is that it's not helping anyone and crafty code !== good code.

He makes a few recommendations about how to keep things simple in the various aspects of your development:

• Know your tools
• Know what you're doing
• Check your smells
• Ask "what value does this add?"

By simplifying things, you give others a chance to look at what you are doing and help you understand what you did right and what you can do to improve that section.

This (and any subsequent posts in the series) will be more limited in scope - a single bad example and a corresponding solution.

This time, the spotlight is on parameterised queries - inserting the variables directly into a SQL statement string versus filtering them or inserting them via a custom query() function. He points out that there's no need to create this kind of filtering/database handling class on your own, though - there's already been one created by the fine folks of PEAR (using the autoExecute function]]> Thu, 26 Oct 2006 09:14:00 -0500