Matt Glaman has written up a post for his site showing how you can write better Drupal code using PHPStan, the PHP static analysis tool.

PHP is a loosely typed interpreted language. That means we cannot compile our scripts and find possible execution errors without doing explicit inspections of our code. It also means we need to rely on conditional type checking or using phpDoc comments to tell other devs or IDE what kind of value to expect. Really there is no way to assess the quality of the code or discover possible bugs without thorough test coverage and regular review.

If you use PhpStorm, you will notice all of their helpers which analyze your code and add static analysis. [...] That's awesome. It's pretty amazing that PhpStorm and a few plugins can give us some stability in our PHP code.

While the functionality in PhpStorm is useful, there are some pitfalls including the fact that everyone would have to use PhpStorm. He makes the suggestion that PHPStan can effectively replace these helpers and, with a bit of customization, provide just as much quality control for your Drupal code. He links over to a custom PHPStan extension for Drupal and an example YAML configuration. He also includes helpful tips around bootstrapping the autoloader, return typing and changes it provides for using the entity manager.

In a new post to his site Nikola Posa takes a look at naming conventions in code and makes some recommendations based on his own work.

In the last couple of months, I spent a lot of time studying Proophessor Do demo project that showcases features of Prooph components, all with the aim of mastering CQRS/Event Sourcing concepts. Along the way, something else turned my attention away from the main topic - unconventional, but clean and concise naming convention for class and method names.

This was a true eye-opener for me, I immediately liked the idea and after adapting it a bit I started practicing it at work. Excited and full of enthusiasm, I shared my findings and opinions with the rest of the world.

He tweeted about his excitement but found that there was more to say and a blog post was the place to put it. So in this post he covers several "anti-patterns" to avoid in code naming conventions:

• Anti-pattern 1: Prefixes/suffixes convention for Interfaces
• Anti-pattern 2: Archetype suffix convention for domain classes
• Anti-pattern 3: "get" prefix convention for property accessors

He finishes the post with some final thoughts and a "TL;DR" image showing a "right" and "wrong" way to structure your code.

Freek Van der Herten has a tutorial posted to his site sharing some customizations you can make to PHP code generation in PhpStorm to fix some issues he's noticed in his own development work in the IDE.

I've been using PhpStorm for quite some time now, but never took the effort to fix a few minor annoyances I had with it.

He shows how to change the generation for:

• Getting rid of the default comment for new PHP files
• Compact docblocks for instance variables
• Fixing the placement of the caret
• Using fully qualified class names in doc blocks
• Changing the default visibility

The final item in the post isn't so much a code generation change as it is a tip for saving these changes and your other configuration options. He shows how to back them up on a git repository out on GitHub.

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.

Tomas Votruba has a new post to his site sharing a listing of some of the more useful and well-established development tooling for PHP and related technologies.

From coding standard tools, over static analysis to instant upgrade tools. This post is going to be a geeky history trip.

Which tool was first? How they build on shoulders of each other?

Are you a lazy programmer who wants to delegate as much work as possible to 3rd party code? Today, you'll become even lazier.

He breaks the article down into three sections, each with several tools linked under them:

• Coding Standard Tools
• Static Analysis Tools
• Instant Upgrade Tools

The items under each link to more information about the tool and provides a brief summary of how it helps you and your code. There's not any examples of them in use, though. You'll need to visit the project's page for more information about that.

Matthias Nobak has continued his series of posts covering software architecture and class structure. In a previous article he talked about using interfaces and in this latest tutorial he covers the reuse of "domain code", the main logic of your application (rather than the structure).

Last week I wrote about when to add an interface to a class. The article finishes with the claim that classes from the application's domain don't usually need an interface. The reason is that domain code isn't going to be swapped out with something else. This code is the result of careful modelling work that's done based on the business domain that you work with. And even if you'd work on, say, two financial software projects in a row, you'll find that the models you produce for each of them will be different in many subtle (if not radical) ways. Paradoxically you'll find that in practice a domain model can sometimes be reused after all. There are some great examples out there. In this article I explain different scenarios of where and how reuse could work.

He then goes on to cover three "reuse" situations, providing a summary for each:

• Reuse-in-the-small
• Reuse-in-the-large and software diversity
• Reuse-in-the-even-larger: reusing entire subdomains

He finishes up the article sharing some thoughts about which of the types seems more obtainable and, in his experience, useful.

Christian Maioli Mackeprang has a new post to his site sharing some of his recommendations of how you can deal with poor code in limited time when making changes (or adding new features) to an older codebase.

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.

His list includes both technical and "people" related suggestions including:

• Ask for help
• Make it easy to reproduce bugs
• Prepare for automated testing
• Get on familiar ground before tackling critical code

For each item in the list he includes a summary of what's involved along with "dos" as well as "donts".

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.

php[architect] magazine has posted the announcement of the release of their August 2018 issue: Masterful Code Management.

This issue includes articles like:

• "Debugging PHP With Xdebug" by Mark Niebergall
• "Pro Parsing Techniques with PHP, Part Three: Using Regular Expressions" by Michael Schrenk
• "MySQL Generated Columns, Views, and Triggers" by Dave Stokes

All of the usual columns are back too including tips for using PhpStorm, using gitflow, secure token management and PHP community. You can pick up a copy to call our own from the php[architect] site and, if you're curious about the contents and want to "try before you buy", they've posted a free PDF of the "Using Regular Expressions" article to give you a taste.

In a post to his site Matthias Noback looks at an interesting idea when it comes to the structure of your code: the idea of negative architecture and making assumptions.

In "Negative Architecture", Michael Feathers speaks about certain aspects of software architecture leading to some kind of negative architecture. Feathers mentions the IO Monad from Haskell (functional programming) as an example, but there are parallel examples in object-oriented programming. For example, by using layers and the dependency inversion principle you can "guarantee" that a certain class, in a certain layer (e.g. domain, application) won't do any IO - no talking to a database, no HTTP requests to some remote service, etc.

[...] A negative architecture is what's "between the lines". You can look at all the code and describe a positive architecture for it, but given certain architecture or design rules, there's also the background; things we can be sure will never happen.

He goes on to give a few examples of "negative architecture":

• "An object does nothing meaningful in its constructor"
• "An object doesn't also fetch dependencies statically if it also gets any number of dependencies injected"
• "If a class is not marked final, it has at least one subclass"
• "If a property is not marked "private", it's used by at least one subclass"
• "An abstract class won't use methods that aren't part of its published interface"
• "If an object has one public method, it won't have any public static methods"

For each item in the list there's a summary (and sometimes code) included to help clarify the point.