In a post to his site Tomas Votruba shows you how to test the PSR-12 standard on your current codebase using some custom PHP-CS-Fixer rules. The PSR-12 standard is a recommendation from the PHP-FIG group about consistency in coding styles and formatting. It expands and replaces the previous PSR-2 standard.

The standard is still behind the door, but feedback, before it gets accepted, is very important. After accepting it will be written down and it will be difficult to change anything.

Try PSR-12 today and see, how it works for your code.

Korvin Szanto, a developer working on the PHP-CS-Fixer project, has put together a commit with the rules to update and enforce the PSR-12 coding standard. The post shows how to install these rules and how to change up your YAML configuration to include them. He also includes a discussion about agreeing/disagreeing with the coding standard idea and gives examples of two rules he personally doesn't agree with.

Tomas Vortuba has continued his series covering the changes in the Easy Coding Standard for Symfony-based applications and the changes in version 4. In this new article he covers the updates around line breaks and legacy fixes.

Legacy code prevention, lines automated and clear naming of classes in huge projects. That all is coming to Coding Standard 4 (still in alpha).

Are you curious what work will now these 4 news fixers handle for you? Look inside.

He then goes through each of the changes and includes both the configuration changes to use it and what code changes it will make:

• Let Coding Standard handle Line Length for You
• Choose Line Length to Match Your Display
• Keep Legacy Far Away with New ForbiddenStaticFunctionSniff
• Prevent & references with ForbiddenStaticFunctionSniff
• Clear Child Class Naming Once and For All with ClassNameSuffixByParentFixer

You can find out more about the standard in this project on GitHub.

The Three Devs and a Maybe podcast, hosted by Michael Budd, Fraser Hart, Lewis Cains and Edd Mann, has posted their latest episode: Carry on Coding.

In this weeks episode we start off discussion with experiences handling online payments, CRM export integration and highlight how PHPStorm can be a great SQL editor. We then move on to mention a service that allows you to easily manage browser polyfills, and Edd chats about his experience currently making a Nokia ringtone composer web application. Finally, we touch upon handling transactional email, depending on third-party services and using Continuation-passing style within JavaScript.

You can listen to this latest episode either using the in-page audio player or by downloading the mp3 directly. If you enjoy the show, be sure to subscribe to their feed and follow them on Twitter for updates when new shows are released.

On the Exakat.io blog there's a post continuing on from a "dos and donts" article about programmer practices. In this new post cover some of the rules in a bit more detail from the original article.

Last week, I ran into ‘PHP Dos and Don’ts aka Programmers I Don’t Like‘ on reddit’s PHP group. It features a list of 11 points that the author hates finding in PHP code. [...] The most interesting point is that coding references are used to asses code. They may very well be automated, thanks to static analysis. I thought it was a good challenge for Exakat.

The list covers several of the rules in the list, providing a brief explanation (and a bit of how it relates back to PHP) including:

• Unnecessary casting
• Extra bracket and braces
• Lack of coding standard
• Too many nested if statements

He ends the post with a bit of detail about how the Exakat service is checking for these "failures" in it's newer "RadwellCode" report. He even gives the scores of some of the more well-known and used PHP projects including the Zend Framework (v1.12), WordPress, Composer and even Exakat itself.

The Toptal.com site has an interesting post mostly relevant to those out there that straddle the line between design and development. It wonders how much coding should a designer know to get the job done.

Many designers think each discipline should mind their own business, while others see no problem in professionals wearing multiple hats. Many developers see designers who code as a threat, while others see it as a facilitator. This is a hotly debated subject, and although I think some great designers are also superb at coding, I will always defend that the more you focus on a particular area the best you will be at it. But this shouldn’t be a reason for you to miss out on the benefits of having another skill under your belt.

The article then breaks down the benefits of designers learning to code by levels of knowledge:

• Step 1: Know the basics of HTML and CSS
• Step 2: Front-end JavaScript and AJAX could make you a unique asset
• Step 3: Back-end JavaScript might be overkill
• Step 4: Database Architecture and Software Engineering Won’t Get Designers Anywhere

For each point there's a brief explanation of the level of knowledge it represents and what he sees as a general designers attitude towards it.

The TutsPlus.com site has posted the next part of their series showing the use of the PHP CodeSniffer tool with WordPress. In the first part of the series they introduced "code smells" and build on that in part two with the installation and use of PHP CodeSniffer to detect these smells.

In the first article of this series, we defined code smells and looked at a few examples of what they are and how we may refactor them so the quality of the code is improved.

[...] Ultimately, we're working towards implementing WordPress-specific code sniffing rules, but before we do that it's important to familiarize yourself with PHP CodeSniffer. In this article, we're going to take a look at what PHP CodeSniffer is, how to install it, how to run it against an example script, and how to refactor said script. Then we'll look at how we're going to move forward into WordPress-specific code.

The tutorial then shows you how to get the tool installed using Composer, not the PEAR method. They help you install Composer then create the simple project with a composer.json configuration file defining the dependency. They provide a sample bit of code to run the analysis against and an example of the output showing violations of the coding standard.

On the SquizLabs site they've shares the results of their coding conventions analysis of PHP projects using the PHP_CodeSniffer tool.

PHP_CodeSniffer, using a custom coding standard and report, was used to record various coding conventions across 193 PHP projects.

They've broken it down by the list of rules included in the default coding standards including:

• Array end comma
• Class defined in namespace
• Function has doc comment
• Adjacent assignments aligned
• CamelCase method name
• Line length
• Spacing before object operator

Each item on the list has the current measurements represented as graphs and a historical view about its previous usage. You can also view per-project statistics for a wide range of PHP related projects.

On the SitePoint PHP blog there's a new tutorial posted from Bruno Skvorc showing you how to use Nitpick CI to "nitpick" over coding standards and rules in your PHP code.

There are many ways to make sure your code respects a given code standard – we’ve covered several before. But enforcing a standard team-wide and making sure everyone knows about mistakes before they’re applied to the project isn’t something that’s very easy to do. Travis and Jenkins can both be configured to do these checks, but aren’t as easygoing about it as the solution we’re about to look at: Nitpick CI.

He starts by getting a sample project bootstrapped and pushes it up to GitHub so the Nitpick service can access it. He then switches over to the Nitpick side and shows the setup of an account and a new project pointing to the newly created repo. He then includes the process and results of two kinds of pushes: non-code (README update) and both a valid/invalid code update. He shows examples of the comments the Nitpick service makes directly on the code and a patch to fix the issues.