One of the things that programmers often talk about is the desire to break programs into smaller components, or functions, so that it makes them easier to trace, easier to read, and easier to debug.
But it’s not all that uncommon to see monolithic functions with a lot of code comments to help explain what’s going on in the program.
I’m not knocking this, really, because I don’t know the constraints under which a programmer was working. That is:
- What was the budget s/he had when building the program?
- How much time was given to complete the project?
- Were there many people working on the project?
- Was the programmer given time to write the code so they could unit test it, refactor it, or merely make it easier to read?
In short, there’s a lot of reason – I believe – that we can read “bad code,” and it doesn’t always have to be the fault of the programmer (that’s just the most natural thing we have to throw out when we read something we dislike).
Does this mean, though, that we shouldn’t strive to refactor or write code in such a way that makes it easier to understand? Of course not. Assuming we have the time to do so, how might we do it?
One of the things that I’ve been making a much more concerted effort, likely more so than I’ve ever done before, is managing separation of concerns between the classes responsible for interfacing with WordPress and those responsible for working with the problem domain.
For instance, let’s say that you’re working on a plugin and it’s going to communicate with a third-party API. Additionally, this plugin will also offer menus, post types, taxonomies, and so on within the WordPress administration area.
There are two areas of responsibility here:
- the area responsible for generally solving the problem,
- the area responsible for interfacing with WordPress.
You can make the case that it’s important to unit test areas that communicate with WordPress, but I also know these are tried and true APIs that have their own set of tests.
Instead, we should be focusing on unit testing and separating our business logic away from WordPress.
But that’s not the point of this post. Instead, it’s more about a way to potentially lay out a project when a portion of it will be interfacing with WordPress.
For whatever reason, there is a consistent tension that exists (at least as far as I’m concerned) between the utility of building something for someone and the amount of time it takes to build the said thing.
By that, I mean that when it comes to WordPress, it’s relatively easy to build small, simple plugins and utilities for others that aren’t necessarily following whatever the modern best practices are.
And, as for this post, I’d say that the modern best practices are something like:
- a server-side package manager,
- a client-side package manager,
- proper unit testing,
- well-designed classes,
- documented code,
- and so on.
And all of that is great and arguably necessary for larger projects (especially because maintenance and consistent development are going to play such a significant role).
Regardless of the library, framework, or code with which you work, you’re likely going to encounter the concept of a boilerplate at some point.
There are a handful of them for WordPress, right 🙃?
But it seems to be an increasingly popular trend that people are creating more and more boilerplates, which isn’t inherently a bad thing, but that there may be confusion as to the purpose of a boilerplate.
Photo by NeONBRAND on Unsplash
So, as defined by Wikipedia (which I think offers a great definition):
In computer programming, boilerplate code or boilerplate refers to sections of code that have to be included in many places with little or no alteration. It is often used when referring to languages that are considered verbose, i.e. the programmer must write a lot of code to do minimal jobs.
But notice there’s a phrase that should not be missed. Specifically:
…that have to be included in many places with little or no alteration.
And in some observations I’ve seen within the WordPress economy, at least, boilerplates seem to require that code be removed, modified, or stripped away rather than simply included or added.
That’s what I hope to clarify.
I’ve had a few conversations with various friends and others on Twitter about the notion of global variables in programming languages. For those who are new to programming or who are unsure as to why they are bad:
The use of global variables makes software harder to read and understand. Since any code anywhere in the program can change the value of the variable at any time, understanding the use of the variable may entail understanding a large portion of the program.
This isn’t to say they don’t have their use, but if you’re interested in object-oriented programming (especially in a WordPress setting where you’re going to be using PHP), then it’s important to understand some better alternatives than global variables.
That is, there are ways to work with passing data around your application without the need for global variables. And one such way is the registry pattern.