One of the things that I love about working with WordPress is the entire hook system – you know, the various `add_action` and `add_filter` calls that you can make in order to manipulate content prior to sending it up to the browser.

I think that it provides a really powerful mechanism for working content prior to saving it to. or retrieving it from, the database.

Now, to be clear, I’m not someone who thinks that everything should be object-oriented versus functional versus procedural. Generally speaking, I think that certain paradigms lend themselves to certain strategies more so than others.

Case in point: The fact that WordPress `functions.php` file is nothing more than a collection of functions is fine with me; however, I really like the fact that I can write plugins using object-oriented programming.

Anyway, one of the the things about the hook system is that it can result in writing repetitive code – which I’ll show in a moment – which can in turn make for very long, very tedious, and very redundant functions.

Or, more generally stated, it can result in less than stellar programming practices.

So when these situations arise, I try to look for opportunities that help to keep functions lean, but yet maintaining a purpose, as well as easy to follow. I think it pays off significantly when it comes time to read back through the code, maintain the code, and to document the code.

Modular Procedural Programming

For example: One of my favorite things about the latest versions of WordPress is the Theme Customizer.

The actual implementation details of the feature are beyond the scope of this post, but have already been covered (so check them out, if you’re interested).

But here’s the thing; The way in which features are implemented can be reduced to a five step process (which is good, in my opinion), but which can also result in repetitive.

First, the process can be distilled into the following:

  1. Create a Section
  2. Add a Setting
  3. Add a Control
  4. Write the necessary JavaScript
  5. Make the call to `get_theme_mod`

For those of who you have worked with the Theme Customizer, you know exactly what I’m talking about.

Lengthy Customization Code

This means that if you’re adding but one new section, the function for doing so can end up looking like this:

Long, tedious, and repetitive, isn’t it?

Now I love the fact that the Theme Customizer has a very clear, capable, and easy to understand API, but when it comes to implementing functions that add new options to the Theme Customizer, I’m not such a fan of large functions.

To that end, I try to keep the functions small, purposeful, and easy to understand.

A More Modular Approach

Take, for example, the following refactoring of the code above:

It’s still a lot of code, but I think that it’s easier to follow and to understand:

  1. The Theme Customizer is registered
  2. A new section is added
  3. Each Setting and Control related to a given section have their own function keeping their implementation small and focused

A bit easier to follow, isn’t it?

For those that are curious, I prefixed the Setting and Control functions with an underscore to denote that these functions are a type of private function, or that they are more closely related to the function in which they are being called – in short, they aren’t meant to be stand alone functions.

They aren’t hooked to anything – they are called from a hooked function.

It’s More Than Trivial

Perhaps you view this as a trivial refactoring – and, in a sense – it is, but trivial refactoring can go a long way in making code easier to read, easier to manage, and easier to document both from an automated standpoint, and from a user stand point.

As developers, the purpose of our job is not just to get something working, nor is it just to get something working well.

It’s also to make sure that the code that we’re writing is easy to follow, well-organized, and can be maintained over time either by ourselves, or by someone else that comes up after us – be it a team or a single developer.

At any rate, this is an example of some of the work I’ve been doing on a couple of projects, and how I’ve found to help make implementation, development, and maintenance a bit easier moving forward.