For as much as I write about – and am a fan of – object-oriented programming, I don’t write much about the times in which I’m working with a procedural code base.

Procedural programming is a programming paradigm, derived from structured programming, based upon the concept of the procedure call. Procedures, also known as routines, subroutines, or functions, simply contain a series of computational steps to be carried out.

Sometimes, I come by this from the requirements of a project, sometimes it’s from a project that I’ve inherited, or sometimes because of something else.

I think it’s important that, as programmers, we don’t hold one paradigm so high that we shy away from working with other ways of writing code. After all, the act of writing code is, at its core, about solving a problem.

How the problem is solved may be considered secondary.

Regardless, whenever I’m working with a code base; however, it’s written, I still try to make sure it’s organized in a way that’s cohesive, as easy to follow as possible, and is able to be maintained over time.

Organizing Procedural Code

I thought I’d share how I approach writing WordPress plugins using procedural programming versus object-oriented programming and how I go about organizing procedural code.

If nothing else, perhaps this will give you some ideas for a current or future project.

Organizing Procedural Code

When it comes to working with procedural code, there’s a lot of potential for including almostĀ everything in a single, monolithic file.

I’m not of this approach because it makes it harder to find where something resides in the file (at least if you’re someone who’s just coming into a project).

To that end, these are the things that I usually do.

  1. Separate Actions and Filters. Typically, I’ll take all of the actions and place them in one file and I’ll take all of the filters and place them in another file. It’s also possible to further separate these files into subdirectories (if not namespaces, too) based on their areas of focus. For example, any actions related to the administration area can go in anĀ admin subdirectory.
  2. Write a Debug File. I normally include a simple debug script in a plugin so that I can easily render debug information on the screen, write to the debug log file, or write to both. This may be a convenience if nothing else, but it helps to provide a way to easily see what’s happening without needing to fire up Xdebug and step through code (unless it’s a more complicated problem).
  3. Autoloader. If you’re using procedural code, you may not be using namespaces at all, but if so then I also include an autoloader that I’ve written to make it easier to automatically include files. This is different than the autoloader than Composer generates, but it still does the same thing.

Obviously, there’s nothing inherently complicated about the above recommendations. In fact, I’d say any one of the above, especially the first step can go a long way in improving the manageability of procedural code.

The Main Plugin File

If you opt to do all of the above, the final version of the plugin’s bootstrap file should be really simple. In fact, it may look like something as simple as this:

Again, this is assuming you’re applying all three recommendations. If not, then your implementation may vary.