In this recent post to his site Paul Jones suggests that "action injection" in PHP applications should be considered a "code smell" (that is, a bad practice that could indicate that the controller class is doing too much).

Circumstance has conspired to put Action Injection discussions in front of me multiple times in the past few days. Having seen the approach several times before, I have come to think that if Action Injection is the answer, you might be asking the wrong question. I find it to be a code smell, one that indicates the system needs refactoring or reorganizing.

He first covers what "action injection" is and provides an example of how it would fit in with the use of a dependency injection container. He also points to some of the frameworks that currently support this functionality natively. With that defined, he then moves into the main idea of the post - that using functionality like this is a "code smell" that could signal something that is in need of refactoring. He then provides some suggestions on things to change and mental shifts in thinking about how your application is organized. He finishes by pointing to the Action-Domain-Responder pattern as a way of implementing this and how single-action controllers can help.

The QaFoo site has a new post showing an interesting practice that could be used in your PHPUnit tests to provide additional functionality without the need for complicated inheritance - the use of traits.

As we already wrote that "Code Reuse By Inheritance" has lots of problems and we consider it a code smell. You should always aim to use Dependency Injection, most likely Constructor Injection. But with test cases in PHPUnit we cannot do this because we have no control about how and when our test cases are created. There are a similar problem in other frameworks, like we discussed in "Object Lifecycle Control". We also blogged about traits as a Code Smell, but let me show and explain why they might be fine to use in your test cases.

They provide an example of where the use of traits might be acceptable starting with a simple test case to check the login behavior with an invalid password. This uses an "is a" inheritance relationship with a parent test class with setUp/tearDown method. This refactored a bit to make use of traits to provide common login functionality based on methods in a trait. The post wraps up talking about traits as a "code smell" despite them seemingly making the test code cleaner, mostly that it limits the ability to change functionality by simply changing the associated code.

Oscar Merida has written up a sort of continuation to this series from Adam Culp about clean code, one that shares more tips on knowing when to refctor.

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.

Adam Culp has posted a three part series to his blog with some guidance about how to create "clean code" in your application development:

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)

Matt Frost has a new post to his blog talking about reducing complexity and preventing overcomplication in your code and application structure.

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.

Following up from the previous article on the Metapundit.net blog, there's part two of the "Code Smells" series - a look at bad things to do in your code (to make it "smell").

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

Following up from the previous article on the Metapundit.net blog, there's part two of the "Code Smells" series - a look at bad things to do in your code (to make it "smell").

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