Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Woody Gilk:
Configuring PHP Style Checks with Composer
Apr 16, 2018 @ 12:03:56

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.

tagged: phpcs style check phpcodesniffer tutorial hook composer

Link: http://shadowhand.me/configuring-php-style-checks-with-composer/

Using PHP CodeSniffer With WordPress: Understanding Code Smells
Jun 13, 2016 @ 12:37:54

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.

tagged: phpcodesniffer smells introduction examples style bestpractice

Link: http://code.tutsplus.com/tutorials/using-php-codesniffer-with-wordpress-understanding-code-smells--cms-26352

SitePoint PHP Blog:
Theming Views in Drupal 8 – Custom Style Plugins
Mar 24, 2016 @ 12:40:30

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.

tagged: drupal8 theme view custom style plugin tutorial

Link: http://www.sitepoint.com/theming-views-in-drupal-8-custom-style-plugins/

James Lewis:
Composition over Inheritance PHP Style
Dec 28, 2015 @ 10:49:45

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.

tagged: composition style inheritance traits opinion

Link: http://blog.jwlewisiii.com/composition-over-inheritance-php-style/

Matthieu Napoli:
Approaching coding style rationally
Nov 13, 2015 @ 11:51:07

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.

tagged: code style formatting rational approach opinion comma docblock interface exception

Link: http://mnapoli.fr/approaching-coding-style-rationally/

Dylan Bridgman:
Writing highly readable code
Jul 30, 2015 @ 12:29:55

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).

tagged: write readable code tips style structure naming convention comments

Link: https://medium.com/@dylanbr/writing-highly-readable-code-94da94d5d636

Rob Allen:
Checking your code for PSR-2
Jul 28, 2015 @ 08:17:20

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.

tagged: psr2 code style check phpcodesniffer phing editor vim sublimetext

Link: http://akrabat.com/checking-your-code-for-psr-2/

/Dev/Hell Podcast:
Episode 39: Animal Style
Feb 24, 2014 @ 10:22:39

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.

tagged: devhell podcast ep39 animal style chrishartjes edfinkler

Link: http://devhell.info/post/2014-02-20/animal-style/

Smashing Magazine:
Why Coding Style Matters
Oct 26, 2012 @ 09:41:32

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.

tagged: code style standard communication tools


Volker Dusch:
Errors will be fixed. Warnings will be 'looked at'
Oct 04, 2012 @ 08:25:43

In a new post to his site Volker Dusch shares his thoughts about warnings in coding style checks (and how they differ from real errors).

When it comes to coding standards there is one rule that always makes me cringe when I stumble upon it: "Lines SHOULD be less than 120 chars long. If not a warning will be issued." Let me try to make a point why I consider WARNINGS in coding guideline checks hurtful.

He defines a warning first, so there's no confusion (something that should be done, but doesn't have to) and why he thinks there's not much of a place for them in the code guidelines. He suggests that, by having them, they take away time from the real issues, the errors. He notes that "should" rules on formatting shouldn't be added to your QA tools right away. Adding too many of these that spit out too many warnings (not errors) could just muddy the waters and make the developers more confused.

tagged: errors warnings qa code style guidelines opinion