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 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?

Continue reading

In yesterday’s post, I talked about a WordPress plugin constructors and the rationale as to why hooks shouldn’t be in the constructor.

Though I mentioned a number of ways to handle hook registration, I didn’t bother to go into details for each of those strategies. As far as I’m concerned, they are deserving of their own article in order to provide as much detail as possible for how to set something up.

For example, one of the methods I shared stated:

• It’s possible to create a class that maintains a registry of objects and the hooks with WordPress.

In other words, it’s about registering WordPress hooks using an object-oriented approach to decrease coupling and increase cohesion among the components in the plugin.

But what does that even mean? What are the advantage does it bring, how is it setup, and how it used?

Continue reading

WordPress plugin constructors seem to be more and more a topic of debate when it comes to what they should define. I’ve talked about it before but it’s okay to revisit a topic like this from time-to-time, right?

After all, there are things we learn and things that we change as we gain more experience.

It’s not at all uncommon to see plugins defining hooks and other behavior, but I’m not a fan of this approach. Instead, I think handling hook registration should be done in its own function or, even more drastically, handled by a set of classes.

But before getting into that, I want to explain what should go in a WordPress plugin constructor, why it should go in a constructor, and how this can be handled when working on your plugins.

Continue reading

In a previous post, I’ve talked about the WordPress design philosophy of decisions, not options. And I’m working towards getting to a point, but I’ve got to set the foundation a bit about the whole thing first.

You can read the entire set of philosophies on this page, but here’s the gist about the one I’ve just mentioned:

When making decisions these are the users we consider first. A great example of this consideration is software options. Every time you give a user an option, you are asking them to make a decision. When a user doesn’t care or understand the option this ultimately leads to frustration.

 

As developers we sometimes feel that providing options for everything is a good thing, you can never have too many choices, right? Ultimately these choices end up being technical ones, choices that the average end user has no interest in.

 

It’s our duty as developers to make smart design decisions and avoid putting the weight of technical choices on our end users.

This is arguably my favorite philosophy that defines what should go into WordPress core and how; though I’d be remiss if I didn’t say I think there are areas for improvement.

(I know this is where the discussion can take a turn into left field but I don’t know to do that, nor am I trying to start armchair quarterbacking.)

But here’s the question:

If there’s an area of the WordPress UI that can be improved by a plugin that does the same set of functionality that already exists in the plugin, is it worth creating the plugin if the feature already exists?

Does it make sense to create WordPress plugins for existing features if the plugin adheres to the “designs, not options” philosophy more so than the core feature?
Continue reading