Thomas Vortuba has a new tutorial posted to his site showing how to easily switch from PHP_CdeSniffer to EasyCodingStandard for enforcing the structure and syntax of your PHP application's code.

Last year, I helped Shopsys Coding Standards and LMC PHP Coding Standard to migrate from PHP_CodeSniffer to EasyCodingStandard.

There are a few simple A ? B changes, but one has to know about them or will get stuck.

Do you also use PHP_CodeSniffer and give it EasyCodingStandard a try? Today we look at how to migrate step by step.

The post then walks you through the five-step process and lists out the major changes:

1. From String Codes to Autocompleted Classes
2. From @codingStandardsIgnoreStart to skip Parameter
3. From 0 and to skip Parameter
4. From XML to YML Config Paths
5. Configuring Sniff Values
6. From Severity and Warning to Just Errors
7. From Beautifier to --fix option

Each step includes either the command required, the configuration changes to make or code examples of the refactor to help illustrate the changes.

Chike Mgbemena has a new post to his site looking at PHP 7 and the abstract syntax tree and uniform variable syntax changes that came along with it.

On my previous post (PHP 7 In-depth Look), I discussed in-depth about the features of PHP 7 (you can read it here if you have not). In this post, I am going to be talking about The Abstract Syntax Tree(AST)/Uniform Variable Syntax in PHP 7+.

PHP 7 introduced a new layer which is called the Abstract Syntax Tree(AST) which helps in decoupling the process of parsing from the pseudo-compile process. Note that this new layer does not have much impact on performance but it make the syntax uniform. Uniform variable syntax/abstract syntax tree aims to establish internally consistent variable syntax, references are accessed from left to right instead of right to left.

He goes on to talk about dereferencing, how it changed from the PHP 5 handling and what IIFEs have to do with it. Some sample code is included showing some of his points and how PHP 7 interprets things slightly different than PHP 7.

Davey Shafik has an interesting post to his site sharing some of his views on the "syntax" of different programming communities - PHP, Ruby, Python and Perl.

In my (almost) three years of being in a developer relations type role I have attended events in several communities and have observed how they differ from my primary community (PHP). As I’ve tried to understand those differences and the reasons behind them, I have had many discussions with members of many more communities also.

After attending my first PyCon (US) I was struck by just how welcoming and diverse the community is and had many conversations trying to understand why this is. This is not what this post is about. This post is about conferences specifically, and how communities place different priorities on different things when it comes to how they run, organize, speak at, and attend events.

He talks about conferences - both attending and speaking at them - and how the situation differs from community to community. He did some background research on why things are they way they are and how that has influenced the overall focus of the community.

On the HHVM blog there's a recent post looking at some of the requirements around traits and interfaces in the Hack language. More specifically, they talk about type checking with traits and how interfaces can be used to help provide extra structure.

In PHP, traits are a mechanism of code reuse that, while very powerful, are also difficult to type check both efficiently and exhaustively. In this post we’ll dive more deeply into the reasons for that and see how Hack solves those problems, allowing you to use traits in a safe way without limiting their expressiveness.

They start by talking about the main problem with PHP's handling of traits (essentially copy and paste into the current class) and how they felt Hack should "just work" in allowing type checking on these "pasted" methods too. Performance limitations prevented them from handling it how they do with other variable types, so they changed things up, using a "require extends" syntax to tell the Hack engine how to allow the checking based on an interface. There's a lot more to it than this, so be sure to read the rest of the post on how they came to that conclusion.

Matt Stauffer has posted the latest in his "What's New in Laravel 5" series today with a look at the changes in creating Artisan commands with a newer, simpler syntax.

If you're not familiar with Artisan commands, they're command-line functions that you can run to interact with your Laravel application. If you run php artisan from the command line in any Laravel application directory, you'll see a list of all of the Artisan commands available for each app. As you can see, Laravel comes with quite a few enabled out of the box.

He starts with a look at the old way of creating the commands using the "artisan make:console" command to build the class and an example of its contents. This version requires a good bit of extra code to reference things like arguments and define required parameters. He then compares this with the new way with a much simpler syntax and reduced about of code overall. One of the main differences he mentions is the concept of a "signature" for the command - a specially formatted string that defines configuration such as required and optional parameters. He finishes the post with a few examples of these signatures.

On the VitalFlux site there's a recent post sharing a few tips (a Top 10 list) of things to think about when doing code reviews.

This article represents top 10 areas to consider while you are taking up the task to do the code review of a PHP project. The other day, I had a discussion with one of the PHP senior developers who asked me about where to start on the task related with reviewing a PHP web application and, we brainstormed and came up with the list. Interestingly, apart from few, most of them can be pretty much applied to applications written with other programming languages as well.

Their top ten list of things to look for during code reviews extend beyond just the syntax of the code and good coding practices. They also suggest things like:

• Adherence to Business Functionality
• Object-Oriented Principles
• Security
• Integration Patterns/Protocols

Code reviews, if done effectively and efficiently, can be a major benefit for producing quality code that not only adheres to standards but also follows good practices and principles (like SOLID).

There's been an RFC that's recently made it through the voting process and was approved for inclusion in PHP6, the uniform variable syntax handling. When these changes are put into effect, some of the odd syntax you had to use for things like variable variables will be cleared up and standardized. However, Derick Rethans stood out as the only "no" vote, here's why...

As you might have heard, PHP developers voted on an RFC called "Uniform Variable Syntax". This RFC "proposes the introduction of an internally consistent and complete variable syntax". In general, this RFC argues for making PHP's parser more complete for all sorts of variable dereferences. [...] Thirty people voted for, and one against: Me. Does that mean that I am against a unified variable syntax? No, I am not. I am actually quite a fan of having a consistent language, but we need to be careful when this hits existing users.

He points out that there's known backwards compatibility breaks in the changes and this breaks the semantics of the language. While the BC breaks are understood, Derick suggests that this is one of the worst changes a language can make: "...and this is exactly why people whine that PHP breaks BC and does not care about its users".

Kevin van Zonneveld has a new post that, while not PHP specific, does have a handy script that will help you stop committing broken code.

Whatever the reason, it's almost 2014 and we are still committing broken code. This needs to stop because best case: Travis or Jenkins prevent those errors from hitting production and it's frustrating to go back and revert/redo that stuff. A waste of your time and state of mind, you were already working on other things. Worst case: your error goes unnoticed and hits production.

To help resolve the problem, he suggests using the "hook" system common to most version control software. In his specific example, he shows the use of a pre-commit hook that fires off a bash script on the files being committed. He includes the full code for this bash script that includes a check for PHP scripts using the built in PHP linter (the "-l" option on the command line). He also includes the commands and updates you'll need to make to get it installed on git.

Phil Sturgeon has another post to his site about a recently proposed RFC for PHP. This time it's about implementing a variadic function syntax in the language. This kind of handling would allow for a variable number of parameters on a function/method and not having to use func_get_args to pull in the list.

An awesome RFC popped up the other day: Syntax for variadic functions, developed by Nikita Popov. I read through it and I loved it, but I did have to Google to see what the hell a variadic function was. This is what happens when you teach yourself how to code. You know how to do things, but don't know any of the words. Variadic functions are already possible in PHP and have been throughout 4.x and 5.x in the form of func_get_args(), which is pretty gross.

He includes an example of how it would work and some of the pros and cons of implementing it in the language including:

• Type hinting (pro)
• Argument unpacking (con)
• Easier documentation in docblocks (pro)
• Keeping up with the "Joneses" (con)

In a new post to his site Igor Wiedler looks forward and suggests some alternate syntax for PHP based around the idea of macros from Lisp. These macros would be parsed at runtime and handled directly as code, compiled down from their custom format.

A very common problem that many software projects have is lack of adoption of new versions. Browsers are an excellent example of this, But it exists on the server as well. [...] This leads to this recursive problem of hosting companies not upgrading because they don't have to, and software not requiring newer versions of their programming language, because they don't want to lose their users. The longer your dependency chain is, the more you suffer from this.

He points out that the easier it is to update these lower level pieces, the simpler it is to introduce new things into your system. He suggest that macro-like functionality for PHP could aid in this goal. He talks some about backporting features and how these marcos could make it easier to upgrade just the things we wanted (or all of them) without having to upgrade PHP itself. He even went so far as to create a tool (galapagos) that does this kind of parsing. His examples implement the 5.4 features of short arrays, $this in closures, function array dereferencing and callable typehinting.

Being able to invent your own syntax is very useful, which instantly becomes apparent when you look at the past. Features get added to languages all the time. What if you could do that easily, within minutes instead of months?