In software development, the concept of a side effect is generally understood to be something like this:

In computer science, an operation, function or expression is said to have a side effect if it modifies some state variable value(s) outside its local environment, which is to say if it has any observable effect other than its primary effect of returning a value to the invoker of the operation.

Side effect, Wikipedia

The Software Engineering Stack Exchange has a great answer. You can read it in its entirety, but I really like how succinct the person puts it:

It’s really very simple. Side effect = changing something somewhere.

There are a handful of ways developers try to mitigate side effects such as automated testing or quality assurance, but when a piece of software is large enough such that each part that composes the system is like a small system unto itself, it’s not difficult to imagine how introducing new code could inadvertently change the state of the program.

This is why any given project at scale is impressive to see work as smoothly as it does. (Sure, projects like large scale web applications, operating systems, are one thing but thinking about medical software, automotive software, the software that runs on airplanes, applications built at places such as NASA, and so on are all the more amazing.)

Bringing this down to the level of stuff I write about and that I work on during my day-to-day – specifically WordPress – side effects are something we’re likely all too familiar with experiencing.

If nothing else, think about the last time you activated a plugin and it immediately conflicted with another plugin or a feature of theme.

  • It could have thrown up a notice,
  • It might have displayed an error message,
  • Perhaps it completely broke the way some part of the way the core application functions,
  • Or it just threw up a PHP error message that wasn’t even clear on what was going on.

To make matters even more fun, the only way to resolve the issue is the disable the plugin via WP CLI or, even more drastic, deleting the plugin.

This is an obvious example of a side effect in WordPress. They can happen for any number reasons, too. Sometimes it’s a matter of running a different version of PHP, it could be a matter of a team not keeping their code contained in its own namespace, or perhaps it’s a matter of not doing enough testing.

Regardless of the case, it’s something many of us have experienced and it’s likely a problem many of us have caused during our careers.

Initially, when I started thinking about side effects in WordPress development, I was working on a plugin that needed to fire when certain events happen during the user management lifecycle.

From there, I started thinking about edge cases and then I started thinking about the overall economy around WordPress and the interoperability and compatibility challenges that come with writing software that runs on top of a piece of open source software that powers so much of the web.

It’s impressive.

Then I was left at a fork of what I wanted to discuss:

  1. Should I talk about the initial problem that kicked off this entire post (that is, making sure I handled all cases of user management)?
  2. Or should I offer general commentary on edge cases and how it relates to work in building WordPress or WordPress adjacent projects?

If you’ve read this far, it’s obvious that I’ve spent more time on the latter than the former. So I’ll save the former for another day.

Since I’ve discussed this at length already, these are a few things – in no specific order – I recommend doing the following things to prevent side effects and conflicts when working on WordPress-specific code:

  • Even if you’re not using object-oriented programming, use namespaces to keep all of your functions contained within their own context.
  • Know the environment(s) in which you’re code is going to run and write for the lowest supported version.
  • When writing a custom function that will fire on a specific hook, take the time to understand the priority and number of arguments the function will expect and write your code defensively (that is, ask “how would I write this code so someone else’s won’t interfere with what I’m trying to do?”)
  • Don’t be afraid of writing unit tests not only to ensure your code is doing what it’s supposed to do but also that it’s not doing anything it shouldn’t be doing.
  • Before writing anything to any type of storage, make sure that the keys you’re using are not already in use and/or make sure to uniquely prefix the keys you’re going to use.
  • Don’t add frontend assets to any page that doesn’t need them.

I don’t know if it’s possible to put together and exhaustive list. But in my experience, these are the things that I’ve found to be helpful especially as it relates to working on backend development.