Tomas Votruba has written up a new post to his site covering the sorting of private methods in classes and why he considers it important to the quality of your code.

When I started PHP in 2004, all you had to do is to learn a few functions to become the most senior dev in your town. Nowadays, devs have to learn a framework, IDE and coding patterns to get at least to an average level.

Instead of reading 346 pages of Clean Code, you need to produce code and learn as you read it at the same time. There will be never less information than it is today. That's why effective learning is a killer skill. Today we learn how to sort private methods in 2 mins.

He starts off by talking about why private method ordering is important, giving an example of a simple class with several private methods. He suggests that, by ordering private methods within the class more related to the functionality that uses them, developers in the system can more easily relate the functionality. He also includes an example of his the PrivateMethodOrderByUseFixer coding standard service to automate this in your code.

Matt Sparks has posted a tutorial to his site introducing one of the more powerful but often misunderstood parts of the PHP language: its Reflection functionality.

Beginning work on the Analyze PHP framework, specifically the container, brought reflection to my awareness. Before that I had maybe heard the term, but I definitely hadn’t used it intentionally. Although it sounds like a scary computer science concept, it’s not. It’s actually quite simple:

Reflection is the ability of a computer program to examine, introspect, and modify its own structure… That’s it.

He starts the tutorial by introducing some of the basics concepts behind reflection in PHP and what it has to offer. He then shares some code examples of it in action getting class properties and getting the constructor. He also shows the use of other built-in PHP functions getting the class methods and the class name.

On the Exakat blog there's a new post sharing five uses of the "static" keyword in PHP applications. This includes the less common static closures and static class names.

Static is a PHP keyword with many usages. It is almost universally used, though there are many variations of it. Let’s review all the five of them :

• static method
• static property
• static closure
• static variable
• static as a classname

The post goes through each of the items in the list giving a brief explanation of how it's used and a code example showing it in action. The post finishes with some tips on evaluating your own code for the use of "static" and tips for each to make your code easier to wrangle and maintain in the future.

The StarTutorial.com site has continued their series covering common design patterns and their implementation in PHP. In their latest article they cover the Template Method pattern.

[This pattern] defines the skeleton of an algorithm in a method, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm’s structure.

In their example, they have two workers that have different schedules but with one difference. Instead of having implementations that differ widely between the two workers (represented by classes) they refactor the main class and allow for a doWork method to be defined in the child. This makes the parent class a sort of "template" for handling the processing with the child filling in the blanks.

Matthew Weier O'Phinney has made a post on the Zend Framework blog about the release of PHP 7.2 support for Zend Expressive, now in version 3.

With Expressive 3 complete, we were able to turn our sights on another important initiative: PHP 7.2 support across all components and Apigilty modules.

The short story is: as of today, that initiative is complete! If you are using the Zend Framework MVC framework, Expressive, or Apigility, or any of the ZF components standalone, you should be able to perform a composer update to get versions that support PHP 7.2.

The full story is much longer.

He starts with a look at the path to get to PHP 7.2 support including the considerations for not breaking backwards compatibility as much as possible. He then moves on to the approach they took with changes to the Composer and Travis-CI configuration changes to make it easier to run the tests on multiple PHP versions (with multiple PHPUnit versions too). The post ends with a look ahead at four things coming soon including a PSR-7-based zend-mvc v4, work on the documentation and more tutorials/guides to help devs make the most of Zend Expressive.

In a new post to the Exakat blog they try to answer the question "how many parameters is too many" when it comes to the structure of the methods and functions in your application.

Now, that is a classic question, that is often a minefield for anyone writing an increasing long list of argument in a method, or simply trying to set up auditing tools.

Obviously, the answer is not immediate. Parameters may be needed, but on the other hands, currying functions allows to reduce the amount of parameter to one for every function. In between, probably exists a reasonable level that is a golden rule, and also very elusive. So, we decided to check the current practice in PHP code.

They started the research with some of PHP's own native functions that took in specific arguments, ignoring those that took an arbitrary number. Next they made a survey of 1900 open source projects to determine the common practice for parameters by function. The results showed that methods without at least one parameter were "less useful" and that a seemingly reasonable amount of parameters is 5. The post finishes with a spotlight of two they found during their research that had the most parameters: a generated class for database interaction and a dependency injection class.

In a new post to his site Matthias Noback takes a look at legacy applications and two things that most of them seem to have in common: classes that are too large and too generic methods. In this post he discusses these two topics and some of the tactics you can use to help refactor and resolve them.

I find it very curious that legacy (PHP) code often has the following characteristics:

• Classes with the name of a central domain concept have grown too large.
• Methods in these classes have become very generic.

He starts by tackling the "classes too large" problem, suggesting that it's usually just a matter of developers slowly adding to existing functionality rather than introducing large chunks of code all at once. Moving on to the "generic methods" issue, he lays out a common scenario showing how a method evolves over time to repurpose it for other uses thank its original intent. He recommends "taking a step back" and picking apart the code to make the functionality more specific in the places it's used.

In a post to his site Sarfraz Ahmed shares a command that can be used in a Laravel application (via artisan) to clean up unnecessary files from packages that you may have installed.

When installing composer packages, they come up with lot of useless files and folders such as .git, tests, readme.md and more. When project becomes bigger with many packages, this junk takes considerable disk space. Since I work with Laravel framework most of the time, I created a command that allows me to automatically delete all these junk files whenever I happen to install or update composer packages.

He lists out the patterns the command matches by default including "tests", "readme*" and "*.log". There's a long list of items and, having worked with several packages, I can tell you that most of the files caught by this need to be removed anyway. He has posted the code on GitHub and provides some examples of the command line calls and how it can be called automatically.

Another package that does something similar but allows the package itself to define the files to remove is the composerclean library that is executed as a Composer command rather than an artisan command.

On the Laravel News site there's a new post sharing some of the new Blade directives coming in the 5.6 version of the Laravel framework.

Laravel 5.6 will include two new form blade directives for cross-site request forgery (CSRF) and HTTP method input, thanks to Taylor Otwell.

The new CSRF handling replaces the previously used format with a simple @csrf tag in the Blade template (inside of the form). The other is related to the method used to submit the form. The new addition allows you to submit the form via something other than POST using the method_field function.

Mark Baker has an interesting post to his site where he shares a suggestion for making it easier to create unit tests for some of the more difficult parts of your unit tests. In the article he shows how to extend final classes and methods by manipulating the AST (abstract syntax tree structure) of the current code under test.

We know that we should always write unit tests for our code, and mock dependencies; but that isn’t always easy when we need to mock classes define as final, or that contain final methods. This isn’t normally a problem when we’re only working with classes within our own libraries and applications, because we control whether they are final or not, and we can type-hint these dependencies to interfaces. However, when the dependencies that we use are from external libraries, we lose that control; and it can become harder to test our own classes if we do need to mock final classes and they haven’t been built to interfaces.

He talks about how one tool, Mockery, allows some of this with its functionality but can still cause issues when mocks are passed instead of actual class instances. He then starts on a solution he has been trying to implement - a mocking library that makes use of the PHP_Parser package to make it possible to modify the structure of the code itself, not just put a wrapper (mock) around it. He includes a bit of code showing how to use that and the BetterReflection library to do some class introspection, locate files for testing and how to the tool to "de-finalize" a class (make it no longer "final").