In a new post to his blog, Leonid Mamchenkov has linked to a resource that aims to help developers refactor their code to use best practices and design patterns: Refactoring.Guru.

Refactoring.Guru is a great resource for learning about refactoring best practices and design patterns. A lot of the website’s content is also available as Dive into Design Patterns ebook.

Today I came across this GitHub repository, which makes this resource even better specifically for PHP developers. Yup, that’s right, the GitHub repository features all code examples written in PHP 7.3, making it super easy to jump into coding.

The repository includes a Composer configuration to pull in some analysis tools and includes examples of about twenty different design patterns in use.

In this post to his site Tomas Votruba covers the create_function function, its deprecation in PHP 7.2 and how to refactor your code to remove it.

If there would be "Miss Deprecation of PHP 7.2", create_function() would definitely win. They can be very complex, tricky and very hard convert to PHP code. Moreover without tests.

Do you have over 5 create_function() pieces in your code? Let's see how to migrate them.

He starts by talking about why it's being deprecated (it's essentially an eval) and some examples of how it could be used to execute code. He then goes through several usage examples and shows how to refactor them into anonymous functions. In his examples he uses a mix of regular code conversions and a sort of hybrid using strings and code to replace the string (probably) used previously with create_function.

In a new post to his site Frederick Vanbrabant tackles the integration operation segregation principle. While the term sounds intimidating, it's just a long way to say something you probably already do: refactor code into smaller testable chunks.

A few weeks ago I attended a DDDBelgium meetup where I was lucky to participate in a refactor workshop lead by Pim and Joop. After the incredible workshop Pim, Dries and me were discussing some code that we refactored earlier . Not so long in the conversation the words “Integration Operation Segregation Principle” casually got dropped by Pim.

Now I’m going, to be honest with you (as I was with them), I had no idea what the hell he was talking about. And maybe neither do you.

He starts with some simple code for a "calculator" class with a calculate method to handle the pricing of a rental car. He includes the test for the class/method as well, using a mock object and several expects calls to handle the method calls. The test ends up being larger than is probably good, so he looks into refactoring the original code to abstract out some of the functionality and make it more testable. In the process this also makes the code easier to follow and, while there is more of it, more maintainable and flexible in the end.

In response to a comment he saw on Twitter about comments in code, Matthias Noback has written up a post with some of his own thoughts.

Recently I read a comment on Twitter by Nikola Poša. [...] He was providing us with a useful suggestion, one that I myself have been following ever since reading "Clean Code" by Robert Martin. The paraphrased suggestion in that book, as well as in the tweet, is to consider a comment to be a naming issue in disguise, and to solve that issue, instead of keeping the comment. By the way, the book has some very nice examples of how comments should and should not be used.

Matthias starts with the suggestion that, when correctly written, code shouldn't need comments to be clear about what's happening. He encourages the use of the "refactor for clarity" method to remove comments and make the code more clear. He finishes the post by breaking down the types of comments (explanatory, todo and "wtf"), what they are/examples and in what situations they can be useful for.

On the TechBeacon site there's a new tutorial posted sharing a list of nine ways to master awful code and make it more efficient, easier to maintain and clearer.

You've been given the task of implementing a new feature on an old codebase, but the code looks awful. How can you understand it as quickly as possible? Here are several shortcuts to help learn the important parts of new code without getting lost in the irrelevant details.

Their suggestions range from technical to non-technical and include:

• Ask for help
• Make it easy to reproduce bugs (add version control, build environments)
• Prepare for automated testing
• At first, work on a small task

For each item in the list there's an explanation and links (or screenshots) of other resources to help illustrate their point.

In a new post to his site Matthias Noback walks you down a road to dependency injection, sharing his process of migrating a codebase from static calls to a more modern, robust dependency injection pattern.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

He talks about this common use case of "statics everywhere" and some of the problems with coupling your code to a static way of doing things. He walks through the steps towards modernization including injecting the container itself into the controller and shifting logic out into services. He also makes suggestions on what to do when constructor injection isn't possible and how to deal with "temporal coupling".

On the Laravel News site there's a new post covering a refactoring of view handling that's possible with recent versions of the framework: using view components instead of view composers..

In software development, one of the “best practices” is to create reusable code that can be implemented in different parts of your application if needed. [...] View composers allow you to move the logic outside your controller and pass the data to the specified set of views. [Using view components instead of composers lets you] reuse complex components using dynamic data on any view within your application.

To help illustrate the difference they set up a scenario of a blog with a "highlights" sidebar based on data from an API response. With view composers you could extract this logic out of the controllers and add it more automatically to the view itself. They point out that this can work for a majority of the situations there's another method that is even more flexible: a reusable component implemented directly on the view. He provides the complete code showing an examples of this components, including a custom Blade directive.

Mark Baker continues his series looking at the use of static properties and methods in applications and how to test them. In this second part of the series he focuses more on some of the unintentional side-effects that could happen when you're trying to refactor them out.

In the first article in this series, I wrote about the problems with testing static methods in classes, and showed a few approaches that allow us to write mocks for statics. Testing classes where we have static properties is a lot harder to manage, because any changes made in any test to those properties are global, across the entire test suite, not simply the test that we are running. Static properties are part of the global state, and we can’t simply tearDown() those changes in the way that we do with instances — at least we cannot easily do so if the property has a visibility of private or protected.

He goes through an example of a refactor from a static property (essentially in the global scope) to a private property. He points out the issue of setting a static value in what seem to be separate child classes, the fact that it actually changes the base value, not the individual ones, leading to potentially unintended consequences.

His main recommendation is to avoid the use of static properties all together. Where that's no possible (like in a legacy project) he offers two potential solutions: either replace them with constants if they're never changed or changing them to instance properties.

In a new post to his site Tomas Votruba shares some of his thoughts about why he thinks the Collector pattern is so awesome. The Collector pattern is one of many design patterns that can be used to create well-structured applications.

I already wrote about Collector pattern as one we can learn from Symfony or Laravel. But they're so useful and underused I have need to write a more about them.

Yesterday I worked on Rector and needed an entry point to add one or more Rectors by user.

He then goes through the process he followed during the refactor and some of the questions he asked:

• Add a Provider?
• Use Expression Language?
• Does Collector Scale?
• Add Tagging?

He finishes the post with one last thought about git history and how it should "tell the story" of the refactoring.

The Pineco.de blog has a post sharing some little snippets of code that can help to keep things cleaner and perform some common operations.

Sometimes it’s harder to keep your code clean and readable than to implement some architecture in your application. We collected some snippets that may help you to refactor your code.

Their list includes code to help with:

• array casting
• type checking
• removing unnecessary "if" statements

They also have several others for different languages on the snippets page of their site for Javascript, Laravel, WordPress and even an .htaccess configuration.