A few years ago, I wrote a post about Setting Up PHP CodeSniffer in Visual Studio Code (and I’ve recently updated it, too).
But it’s been four years since that post was originally written and, in that time, a lot can change in terms of how we write code.
Four years is roughly an Internet Age, isn’t it?
Anyway, the basic points of that article still stand, but if you’re working on a variety of projects and some of them require different configurations, settings, and standards, then the way you go about installing and configuring PHP CodeSniffer may be different than how you configure it on a system-level.
So if you’re in that position, here’s how you can configure PHP CodeSniffer on a per project basis using Visual Studio Code.
Everyone has a different git workflow set up but for the purposes of this post, assume that you’ve got something like the following:
- A branch in which all of your assets, unbuilt, reside.
- A system of continuous integration that builds the assets and creates a new branch or perhaps a new version.
- A branch that’s created by the continuous integration system that contains the built assets.
The main component of this workflow is the continuous integration system. That is, if it fails, then the work responsible for building the assets and creating a new branch no longer work.
And when that happens, we’re left having to do it manually. It’s tedious, sure, but not difficult. If you find yourself in this position, here’s how you can go about building assets, merging git branches, and creating a versioned release.
But as both my family [and I] have grown and as WordPress has changed over the past half-decade (let alone decade), that entire perspective has changed.
Not just that, though.
For as long as I’ve been writing on this site, I’ve used a combination of syntax highlighting, GitHub gists, or
pre tags to help share code relevant to a given post.
But the more technical articles I read and the more that I see we, as an entire industry, start to rely versus utilize tools of Stack Overflow and other sites, the more I wonder how much we really understand what we’re writing (or even care) so long as the end results just works.
This isn’t a commentary on how quickly we should ship something. Instead, it’s about how we solve a given problem while also truly learning what it is that we’re incorporating into our codebase.
Remember that WordPress uses the event-driven design pattern and although we often refer to actions and filters, the concept comes down to hooks. The flow of control through the program goes something like this:
- Execute the program,
- Whenever the program comes upon a hook (in WordPress, we’ll see
apply_filters), iterate through all of the registered hooks,
- Return control back to the program,
- Execute until the end.
This isn’t completely different from the Publisher/Subscriber Pattern (or PubSub, for short) but there’s a key difference: The Event-Driven Pattern simply signals that something has happened and if there are hooks, they will fire. The PubSub Pattern will tell a registered subscriber to do something.
Anyway, back to hooks in WordPress. Keeping the two concepts of hooks that we have may be most easily done by thinking of them like this:
- Actions are for doing something,
- Filters are for processing data.
If you’re looking to approach WordPress development in an object-oriented fashion, tightly coupling your code to WordPress core by registering your classes via hooks to the core application is not a good idea.
In other words, don’t register your business logic with WordPress. Keep them separate. Here’s a litmus test for if your work is tightly coupled with WordPress: If you can’t run a unit test against your class without loading WordPress, it’s tightly coupled.
So what’s the solution? Delegation.