The TutsPlus.com site continues their series covering the use of the PHP_CodeSniffer tool with WordPress in this latest post. In this new tutorial they show you how to install and use the WordPress-specific coding "sniffs".

If you're just joining the series, we've been discussing the topic of code smells, how to refactor them, and tools that are available to help us automate some of the monotony that comes with doing so, especially within PHP programming.

[...] If you've made it this far, I assume you're a WordPress developer, and you're interested in getting PHP CodeSniffer configured such that it can sniff out any problems in your code as it relates to the WordPress Coding Standards. That's good! Because in the remainder of this article, that's exactly what we're going to cover.

The tutorial helps you install the WordPress sniffs and how to add them to the standards supported by your local phpcs installation. The command to execute them against your WordPress plugin is included as well as example output and how to refactor those issues away.

On the TutsPlus.com site there's a tutorial posted about using PHP CodeSniffer with WordPress, a popular PHP coding standards tool that helps enforce common coding practices and style in your application.

Oftentimes, the way in which we write code depends on how we got started with programming. [...] In this article, we're going to take an introductory look at code smells. We're going to examine what they are, what they look like, and how they often manifest themselves in the work we do. We'll be using PHP for our examples.

They start with an introduction to the topic of "code smells" including a few examples along with matching code snippets:

• Example 1: Clear Naming Conventions
• Example 2: Stay DRY
• Example 3: Long Parameter Lists

They also include some solutions that can help you avoid these "smells" in your code and refactor out ones that might already exist.

In this new post to his site Chris Hartjes gives an example of what he calls a "testing smell". This particular illustration deals with the poor handling of testing and exceptions with try/catch blocks.

As part of a project to migrate the PHP code at work from PHP 5.2 to PHP 5.4, I’m using our extensive test suite to look for instances where something that changed between the versions of PHP that we are using has caused some unexpected behaviour. In one of our code bases, I found some tests that are exhibiting a test smell through their use of a try / catch block in the test itself.

He includes a (contrived) example showing the use of an exception in a unit test to run an assertion in the "catch" for the test to pass. He points out that this particular check is being done to see if the user input is valid...and that it's a bad way to enforce it using exceptions. He also suggests that if you have an "if" situation, don't use one test with logic in it, write two tests. He mentions a disenting opinion but notes that a failing test is a failing test, regardless of what caused the failure.