I’ve been seeing a lot of a new trend in coding, which stems from boilerplate plugin code, and that is the use of suffixes in function names. This has become increasingly popular in WordPress code and I, for one, am not a fan.

WordPress Function, What’s Your Function?

Otto likes to say that well named functions don’t need code comments.

While optimistic in this day and age of complex code, the basic concept remains quite valid. If you name your functions well, the chances are that they will trigger your contextual memory and you’ll remember what they are, what they do, and why they’re there. To this end, the difference between function activate_pluginname() and function pluginname_activate() is miniscule. Both of those are clearly functions that run on ‘activate’ and that makes perfect sense. We can see the purpose of the function by its name, and that is the majority of Otto’s point. They are well named as they indicate their job. The issue then does not like in the name of the function but in the format of the name of the function.

Function Name Conflicts

A majority of the time, my argument for having unique function names is that there are over fifty-thousand plugins out there, and the odds of two of them having the same function name is quite high, for cases when the function name is generic. For example, function my_plugin_init() is not unique in the slightest. Yes, people literally use my_plugin_ as a prefix. That’s not a placeholder. That particular error occurs when people use boilerplates and don’t read the directions clearly. Most state “Search and replace my_plugin with your plugin prefix.”

Preventing conflicts means it’s incumbent of developers to select unique function names. Now this pressure is alleviated by the use of namespaces and classes, but even those have to be unique to their plugin (or theme). After all, class WordPress is not a great classname.

Again, in this regard there is very little difference between function activate_pluginname() and function pluginname_activate() in the real world. Both are unlikely to cause conflicts.

Internal Consistency is Good

Another aspect of names is that good function names are logical and consistent. Few things pain me more than seeing function pluginname_init() and function pn_admin_init() (where pn is an abbreviation for the plugin name). What I see a great deal with the plugin name as suffix is this hodgepodge of names:

  • init_plugin_name()
  • plugin_name_uninstall()
  • pn_wp_class_list()

My guess at this point is that any time a particular boilerplate doesn’t specify the name of the function needed, people fall back into old habits. Or rather, they fall back into the recommended habits. You know, a prefix. Consistently named functions make it easier for people to recognize what function belongs to what plugin or theme.

So why Prefix?

This takes us to an interesting point. Both function activate_pluginname() and function pluginname_activate() meet the requirement of being well named and unique (and can be consistent). So what actually is the problem here?

The problem is the future.

Your code does not exist in a vacuum! Code that will only ever be used on your own server still runs with the other plugins and themes you add, and they could cause a conflict. It’s somewhat trivial to change those things, but it’s not fun and usually it means that you broke something in your live environment.

  • Consistently named functions make it easier to know what function relates to what.
  • Uniquely named functions are easier to find.
  • Well named functions remind you what the function is supposed to do.

But again, why prefix?

Remember Who Comes Next

I do a lot of searches on code in myriad plugins. More than most people involved in WordPress I suspect. I have a very peculiar relationship with plugins, after all. When the core developers want to figure out how ‘well used’ a function is before changing it, I help out by running a search on all the code in the plugin directory. This results in me finding a lot of weirdly named functions that require me to track back through the plugin and find out what it’s really doing. When things are prefixed, this search goes a lot faster.

Besides just my convenience, when you remember that your code is used by thousands of people, they will have an easier time searching for your code when they have an error. If you got an error that a function named halfelf_init was doing something wrong, you could run this to find the file: grep -r "halfelf_init" ./wp-content/

Some of the more experienced debuggers out there are probably wondering why I grep from wp-content when most errors give the full path of wp-content/plugins/plugin-name/filename.php in the first place. The answer to that is “most” but also because often functionality plugins that are related to a theme (or other plugins) will cross-reference themselves in ways that can cause PHP to give you the wrong file for the problem.

If you ran my check and found that the function was called in nothing but files in that plugin’s folder, great. But if you found it was called in a theme, you would then want to run this: grep -r "halfelf_" ./wp-content/themes/theme-name/ — That would reveal all the calls for the functions that belonged to a specific other tool.

And what if you got a warning that the function had already be declared? grep -r "function halfelf_" ./wp-content/plugins/other-plugin/ will list all the functions that start with halfelf_ and save you a headache of solving one warning only to have it be replaced by another. (Of course, if you use namespaces or classes, this gets thrown out the window, oh well).

Finally there’s the human factor. This is exceptionally subjective, I know, but doesn’t a line of functions all starting with the same term feel cleaner to you? It demonstrates a repeating pattern that a human mind can follow and feel comfortable with.

Solution: Be Consistent

There’s only one solution to be had here. While I greatly prefer a prefix, if you chose to use a suffix, be consistent. Make every single function end with _pluginname and don’t skip a single one.

Reader Interactions

%d bloggers like this: