Tomas Votruba has continued his series covering the use of the Symfony Console component with a new tutorial. In this latest article he shows how to get "stylish and standard console output" using the output formatting included with the package.

Even if you don't use any component from Symfony or even installed one, you can use this trick in your PHP CLI App.

It's simple, provides standard and makes your output look like a design from Apple - useful and nice at the same time.

He starts by introducing the OutputInterface that the Symfony Console package includes and shows a few screenshots of the difference between normal console output and the Console component's look. He also covers the SymfonyStyle functionality that allows for even more fine-grained control over the input and output handling of your application. He finishes the post showing a few tips on integrating these styles into your command line application and setting it up to fetch SymfonyStyle as a service.

In a new post to his site Woody Gilk showing how to use custom Composer hooks to run PHP style checks (using PHP_CodeSniffer) on your codebase and setting up the same configuration for all developers.

One of thing that has always bothered me about phpcs is that the lack of a local configuration file.

The official way to set the default standard for a project is [to set the standard on the command line]. This will write to a configuration file inside the vendor/ directory, which means that the configuration cannot be committed to version control. When a new team member is added they must also run this command or different style checks will be used.

Luckily, this can be solved with composer command events, namely the post-install-cmd and post-update-cmd events, which can be pointed to a PHP class that processes the event.

He includes the configuration changes showing how to set up the command in the Composer configuration to run post-install/update and the code required to set the phpcs standard to use. While this method works, he has also updated the post with an example of a single (XML) configuration file that accomplishes the same thing.

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.

The SitePoint PHP blog has another post in its series about working with Drupal 8. In this new tutorial author Daniel Sipos talks about theming views in the content management system and introducing custom style plugins.

In this article, we are going to look at how we can create a custom Style plugin for Views in Drupal 8. We will use the Bootstrap tab markup as a goal and implement a tabbed output for our View results. In the View configuration, the Style settings will allow us to specify which field will be used as the tab navigation copy, leaving the rest of the fields shown in the respective tab panes. Basically, each View result will represent a tab – so this example is not suited for Views which have more than a few results. The main goal is to illustrate how we can create our own Views Style plugins in Drupal 8.

He starts by talking about Style plugins - what they are and where they fit in the application execution flow. He then walks you through the creation of the custom style plugin to integrate the Bootstrap tabs. This also includes the creation of the theme and the matching template to build out the tab markup.

In this post to his site James Lewis makes the suggestion that you consider composition over inheritance when it comes to writing your object-oriented PHP. That is, using PHP's traits functionality to compose interfaces with only the functionality needed, not other possibly useless things.

So what does “composition over inheritance” mean? [...] Lets dive into an example written in PHP to help us better understand composition over inheritance. [...] Almost all modern programming languages have a way of dealing with composition, PHP has Traits. Traits where introduced into PHP at version 5.4 and the PHP docs describes traits as a mechanism for code reuse.

He starts with an example of using inheritance to create new "animal" types but points out that this can lead to extra functionality as sometimes your Robocat just doesn't need to eat. He then introduces traits as a way around the issue, creating traits for each piece of functionality and using PHP's use statement to include only the ones needed for that particular kind of object.

In a post to his site Matthieu Napoli shares some of his thoughts about "code style rationality" including code formatting in general and some suggestions on one of the harder things in development - naming things.

Habits are sometimes making us blind. We think X looks prettier than Y but that’s just the habit speaking. In this article I’ll try to take a rational approach at coding style. That means leaving the “it looks ugly/better” at the door.

If at any point you feel like something “just doesn’t look good”, breath in, breath out, and try it! Nothing beats hands-on experience, not even some random article on the internet.

He looks at a few subjects specifically (there's way too many to cover them all in detail):

• the use of trailing commas
• alignment of values in docblock comments
• keeping docblock comments minimal
• using the "Interface" suffix
• using the "Exception" suffix

He ends the post by reminding readers that the point is to think about code style logically and that no rules are written in stone.

Dylan Bridgman has posted a few helpful tips on writing code that's "highly readable" and easier for both developers inside and outside the project to understand.

We are always told that commenting our code is important. Without comments other developers will not be able to understand what we did and our future selves will recoil in horror when doing maintenance. Readable code, however, is not only about comment text. More importantly it is about the style, structure and naming. If you get into the habit of writing easily readable code, you will actually find yourself writing less comments.

He breaks it up into a few different categories to keep in mind as you're writing your code:

• the overall style of the code
• the structure of the application (directories, libraries used, etc)
• naming conventions for variables, methods and classes

Finally, he talks about comments and how they should fit into the ideas of readable code. He suggests that they should stay as high level as possible and explain the intent of the code, not what the code is doing (yes, there's a difference).

Rob Allen has posted a guide showing you how to make your code PSR-2 compliant with the help of some handy tools, both in and out of your editor/IDE.

Most of the projects that I work on follow the PSR-2 coding style guidelines. I prefer to ensure that my PRs pass before Travis or Jenkins tells me, so let's look at how to run PSR-2 checks locally.

He looks at three different methods - not the only ones out there but three quick to implement ones:

• Using the PSR-2 sniffs for PHP_CodeSniffer
• Automating the checks with Phing
• Editor integration (he shows VIM and Sublime Text)

There's links to the tools mentioned here and screenshots/configuration information showing how to get it set up too.

The latest episode of the /Dev/Hell podcast, hosted by PHP community members Ed Finkler and Chris Hartjes, has been released - Episode 39: "Animal Style".

This was recorded the night before SkiPHP started, which was an awesome PHP conference in Salt Lake City. We ramble about a lot of stuff, including our first conferences, America’s first serial killer, our approaches for giving talks, and Chris’ secret identity.

You can check out this latest episode either through the in-page player or by downloading the mp3 directly. If you like what you hear, consider subscribing to their feed to get this and future episodes.

On the Smashing Magazine site there's a new article talking about coding style matters with developing projects with multiple people (or even possible contributors in the future) involved.

Coding style is how your code looks, plain and simple. And by “your,” I actually mean you, the person who is reading this article. Coding style is extremely personal and everyone has their own preferred style. You can discover your own personal style by looking back over code that you’ve written when you didn’t have a style guide to adhere to. Everyone has their own style because of the way they learned to code.

They talk about how everyone has their own personal "style" to their code and how, when working with a team, everyone needs to communicate and make sure their styles match. They also make a few recommendations for your code like leaving "clues" (comments) and making errors easier to spot. There's also a few links to tools that can help keep your code standardized including CSS Lint and the Eclipse code formatter. PHP, of course, has its own - PHP_CodeSniffer with its own rules.