Back in 2011, I was doing a lot of reading on working with legacy code, code quality, and refactoring.

Refactoring WordPress-Based Code

There’s a quote by Martin Fowler (who literally wrote the book on refactoring) attributed to Uncle Bob that’s stuck with me – and I’m sure many, many programmers – ever since:

always leave the code behind in a better state than you found it

The thing about this particular idea is that I think it might sound a bit more idealistic until you really start to try to practice it in everything that you do.

That is, if you take it at face value it sounds like anytime you need to work on a codebase, then you need to leave the entire codebase better than when you found it. But the more I’ve tried to apply this rule in my day-to-day work, the more practical, the cleaner, and the more maintainable WordPress-specific code has become.

So when it comes to refactoring WordPress-based code, what does that look like?

Refactoring WordPress-Based Code

This isn’t going to be a long post. Instead, I’m simply going to share a few bullet points that I follow when it comes to working on code that I’ve previously written, that I encounter from others, or that’s from a codebase I’ve worked on with others in the past.

In no particular order:

  • Don’t Be Idealistic; Be Practical. Refactoring an entire codebase isn’t something that’s practice especially if the codebase isn’t wrapped in unit tests. Look at the code you’re working on and see what minor modifications you can do to improve it.
  • Use the Latest Standards. You don’t need to set up an entirely new development environment for older code. Instead, just make sure you have good code sniffers in place. If you’ve moved from the WordPress Coding Standards to PSR, look at the warnings or notices that the sniffers throw and attempt to update the code just in that file (or set of files).
  • Write Helper Functions. If your functions are too long, look for ways to make them easier to work with. First, update any control structures like loops or conditionals, then write helper functions to make those easier to read.
  • Add Tests (When Possible). If you have a unit testing framework already in place, then add tests for your new code. If you don’t have the time or don’t have the framework, don’t sweat it. As much as pragmatic programmers preach it, there’s not always time to add tests. (This isn’t to be a statement that they aren’t useful or shouldn’t be included, but that it’s not always practical to incorporate them at any given time).

Some of the things that I’ve found myself doing in recent projects include simple things, too:

  • updating variable and function names to follow PSR,
  • changing tabs to spaces,
  • adding helper functions to make conditions and loops be more readable,
  • splitting up classes to they have a higher degree of cohesion,
  • improve the docblocks of each function

These are just some of the example and this is clearly not an exhaustive list. But that’s not the point. Instead, I’m looking to simply share how you can apply refactoring WordPress-based code all the while getting your day-to-day work done in a manageable way.

All of the above changes or recommendations are things that can usually be done with help from the IDE, a few shortcuts, and with maybe a half-hour of extra time (and I’m being liberal with that estimate).

So, no, you don’t have to rewrite an entire codebase. I don’t even know if that’s a practical goal for which to aim. But you can fix one little piece of the overall system for which you’re responsible?

And why not at least aim for that?