Check out the second post on passing variables in WordPress in loops.

One of the most minute aspects of writing code is opting when – or when not – to use variables.

It sounds like a trivial decision, right? And in some respects, it is, but the longer I’ve been writing code (or, perhaps a better way to put it), is that the more code that I’ve written and had to maintain, the more my opinion has changed on how frequently I use variables.

After being in the industry for a couple of years, I tried to follow the this rule of thumb:

“Only if I need to use this value more than once, then I will store it in a variable.”

And I still think that’s a decent rule of thumb, but the more I’ve worked with systems that, say, interface with a database, or that leverage multi-dimensional arrays, or that some type of iteration (be it an each iterator, a foreach iterator, or something similar), the more I’ve found how storing a variable – even if it’s only going to be used once – can make for slightly more readable code.

Passing Variables in WordPress

Variables are one of the foundational elements of programming, so to spend time talking about them in a single blog post may seem a bit excessive.

And maybe it is.

But, the way I see it, if you’re not critically evaluating everything you’re doing as it relates to writing code periodically throughout your career, then your habits will never grow beyond what you’ve started out doing.

Passing Variables in WordPress

With that said, as small as an idea as this may be, it’s still something that I’ve found to be more useful over time not only in the code I’ve written, but in working with code others have written, as well.

In the context of WordPress, here are two examples where I’ve found declaring variables, even if they are only going to be used once, to improve the code.

An Example with WP_Query

A lot has already been said, written, and shared about <a title="WP_Query" href="">WP_Query</a> and that particular class isn’t even the point of this post, save for the fact that the constructor accepts an array of arguments that can be relatively complex (at least as far as multi-dimensional arrays are concerned).

In short, I think that setting up an array of arguments prior to getting an instance of the class makes for a bit neater code.

For example, see the following gist:

In the first example, I’m instantiating WP_Query and storing it in a variable that will be used through the typical WordPress if/while flow of control.

But the difference is that following coding conventions while also nesting the array of arguments into the constructor not only looks ugly (and yes, I think there are aesthetics to how code is formatted), but it makes it difficult for someone to come along and know exactly what we’re passing.

Sure, you can look at the documentation for the class to determine what the array represents – in this case, the arguments for the query – but having a single variable named $args makes it that much clearer as to what is being passed.

Then, in the second example, I first define a couple of variables that are used only once throughout the instantiation of the class. Specifically, I first define the $term_id that I’m going to use in the taxonomy query, then I define the $args array that I’ll pass to the constructor.

Ultimately, I think that it makes it a bit more aesthetically pleasing, makes it easier to maintain over time, and makes it possible to write a greater number of shorter lines of a code.

There’s Always More

Of course, this is but one small example within a significantly larger context.

I think the general idea still works regardless of the language or environment (so, say, JavaScript is also another candidate) in which we’re working.

Naturally, this is not just restricted to WordPress either. It just so happens that that’s where I spend the majority of my time these days, and that’s the foundation about which I write the most.

There are also other times in which this can be useful – such as in the case with, say, foreach loops that I’ll talk about in the next post.