In the last episode of WP Late Night, there was a brief debate about plugin size. Ryan expressed a preference for smaller plugins with tightly focused functionality. It’s natural to worry that, as the number of lines of code increases, so does the likelihood of bugs, and performance slowdowns.

This concern makes sense if you’re assuming plugin code is not very well organized and not very well tested. Unfortunately, that’s a safe assumption with many plugins. As plugin authors, we should have higher standards for our work. There are two things that come to mind:

1. Optimizing the readability and maintainability of our code. This means writing “clean code” (the subject of my Philly WordCamp presentation). It reduces the likelihood of bugs, and makes our plugins easier to enhance and adapt to changing needs. It also makes it more likely that others will contribute to the project, or learn from it, and start writing better plugins themselves. These are some one of the main attractions for participating in the WordPress open source community, right?
2. Optimizing for performance: one aspect of the “clean code” philosophy is to not prematurely optimize code for performance, especially when our guesses about how to do that are often wrong.
   

   More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.

   Wulf, W. A. “A Case Against the GOTO,” Proceedings of the 25th National ACM Conference, August 1972, pp. 791-97.

The rule of thumb is to optimize for readability and maintainability first. If a performance problem comes up, it is likely stemming from a small area of the code, and you can focus your performance optimization efforts there. As one person put it: “There is far, far more money wasted on fixing and customizing and maintaining hard-to-read code than there is lost on inefficient code.”

There are many techniques involved with writing clean code. A foundational one is following the Single Responsibility Principle (SRP). Bob Martin has a very succinct definition of the SRP: “a class should have only one reason to change.” In his book Agile Software Development, he explains further:

If a class has more than one responsibility [more than one reason to change], then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the ability of the class to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

If you follow the SRP, then it doesn’t matter how big your plugin is. What matters is how you use it.

The trick, of course, is figuring out what it means to have a single responsibility. WordPress itself helps you figure this out. When you call a WordPress hook or filter, it’s likely that you will want to create a class that implements what you intend to do for that hook or filter call. For example, if you call add_shortcode, then you should have it instantiate a class that implements your shortcode. If that class needs to change, it will be only because your needs for the shortcode have changed. The shortcode logic is not tightly coupled to other parts of the code. Removing that coupling is an important step towards also removing that sinking feeling of fear when you start monkeying with the innards of some gigantic application.

Not every hook and filter call deserves its own class. Some are merely stepping stones to others and do not need their own class. For example, if you call admin_menu simply for the sake of calling add_options_page, one class is enough. Others may need more than one class to support them. But for getting your feet wet, having a class per hook or filter is a good place to start.

My Post to Post Links II error: No post found with slug "shashin-wordpress-plugin" has a total of 55 classes and subclasses (you can see the code on GitHub). How can you find what you’re looking for in all those classes? It sounds horribly bloated for a WordPress plugin, right? It’s actually the opposite.

A coding habit that goes hand in hand with the SRP is the use of meaningful names. Each class in Shashin serves a specific purpose, and has a name that tells me what it does. If I need to make a change to the settings, I go to the Settings class; if I need to make a change to how album synchronizing is done with Picasa, I go to the PicasaSynchronizer class, etc. The majority of the classes are less than a couple hundred lines. With small, well-named classes and methods with clear purposes, when there is a bug, it’s usually not hard to find. And if I need to change something, I can make that change in one place with a greatly reduced fear of breaking something unrelated.

By using a class autoloader, such as Post to Post Links II error: No post found with slug "toppa-plugin-libraries-for-wordpress", you can also save yourself the trouble of figuring out where to put require_once statements, for loading your class files. With an autoloader, a class file is loaded only when “new” is called (so if you are worrying about performance with so many objects, they are only loaded when they are actually needed). How you keep track of object dependencies, and when and how you instantiate your classes, are what I’ll write about in my next post, which will cover using an injection container.