I don’t know if there’s a standard for what’s considered “clever code,” but I think that if you were to show various code samples to programmers, they’d be able to know it when they see it.

And there used to be a time in my career that I was far interested in writing clever code. But the older I get and the more work I do in maintaining projects, the less concerned I am about writing clever code and the more interested I am in writing code that’s clear and read and thus maintain.

Clever Code with Arrays

Clever code is for the birds. Pardon these stupid puns.

When we work with WordPress, we’re likely dealing with arrays a lot especially given that so much of the internals of WordPress are built on them (yes, there are some objects too, but arrays are pervasive).

What, then, does clever code with arrays look like in WordPress versus less clever code? And furthermore, should we avoid aiming to write clever code?

Clever Code with Arrays

Array functions are arguably one of the largest set of functions in PHP.

Naturally, writing clever code with WordPress seems to fit part and partial with the environment, right? I’m not saying it’s bad at all. I’m just saying that when you have functions in the global namespace that work with arrays that return arrays, it’s far too easy to write nested calls that ultimately require a bit more mental work to parse what the code is doing.

Sure, writing about it is one thing, but maybe it makes sense to look at an example of what clever code with WordPress might look like and then how it can be refactored.

An Example

Say for example we have a post and we’re updating the post excerpt so that a name that’s contained within the excerpt needs to be removed. When this happens isn’t necessarily important (although delete_user isn’t hard to imagine, right?)

From the outset, we’re given:

  • the post ID,
  • the name of the person to remove.

One way to do this would be to use a combination of array, array_map, explode, array_diff, implode. All for this reason:

  • array to create an array of the person (because it, as an array, is required later),
  • array_map for trimming white space after exploding the excerpt into an array,
  • array_diff for finding the strings that are left after removing a name,
  • and implode to rebuilt the result back into a string for the post_excerpt.

Okay, so with that said, here’s what an example of what clever code in WordPress may look like:

But it’s a lot of nesting, and we usually have to start from the outside in and know what each function is doing, right?

To clean it up, we still have to deal with the functions that are listed above, but we can break things down into easier to read steps (along wth code comments) to make it easier for another developer to parse.

Perhaps it could look something like this:

Now, is this the way to do it? I don’t know. But it’s way to do it. And it’s one of those situations that’s easier to read and to follow.

So perhaps it’s not writing clever code in WordPress, but I don’t know – nor think – that should be out goal.

Should We Aim To Write Clever Code?

The WordPress Handbook states the following:

In general, readability is more important than cleverness or brevity.

And then proceeds to give an example. At this point in my career, I tend to agree:

  • clever code does not equate to more performant code,
  • clever code often takes longer to jump through more mental hoops than verbose code,
  • clever code is thus harder to maintain especially when jumping into an older codebase.

Finally, I think different people might consider some code more clever than others, but there’s also code that many of us would consider an attempt to be more clever than not.

Ultimately, aim to write code however it is you want to write but write with another developer in mind: If you’ve ever complained about a piece of code being tough to decipher at first glance, odds are it was poorly written or it was an attempt to be clever. So don’t be that guy or girl who’s passing the buck to the next developer.

Instead, aim to write clear code and use comments when necessary.

Category:
Articles
Tags:

Join the conversation! 5 Comments

  1. More readable code is the way to go. I always tell my team to avoid nesting & instead split them as above. It helps when debugging issues. Otherwise debugging an issue in nested code can sometimes take longer then it would otherwise take.

  2. As tremendous as native PHP array functions are, the way that nesting reverses the natural reading order of operations makes them far less useful than I’d like them to be. In these cases, I really like to use the collections package from TightenCo (https://github.com/tightenco/collect) to give me the flexibility to write succinct chained transformations while keeping it easy to read. I threw together a quick example here: https://gist.github.com/johnpbloch/3129c031e7b6b6035bc361ac05ef5d25

    There’s also an RFC in the works to add a pipe operator to make these functions easier to chain without losing readability: https://wiki.php.net/rfc/pipe-operator. It’s still under discussion, so who knows if it’ll go anywhere, but it’s an interesting idea.

    • As tremendous as native PHP array functions are, the way that nesting reverses the natural reading order of operations makes them far less useful than I’d like them to be

      Yes. At the end of the day – at this point in my career – I’m opt to go for readable over the ability to nest the calls like in the first gist in the post.

      I threw together a quick example here:

      I really do like these chained calls. We’ve seen other JavaScript libraries do something like this and though people may argue it violates the law of demeter, it makes things so much cleaner (like you said).

      It’s still under discussion, so who knows if it’ll go anywhere, but it’s an interesting idea.

      Agreed! It’ll be fun to follow and I hope it works out.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.