By using a unified naming convention you know where the class you need is declared, to be able to load it into your code. The mind forgets easy, and you want to focus on solving your programmatical problems instead of trying to remember where you put your six weeks old myURLHelper class.
This is a follow up on my last post about the directory structure of WordPress plugins. Previously I grouped the PHP files in directories based on functionality, such as “admin”, “js” and “widget”. Now it’s time to refactor this. This does not apply only to WordPress plugins, but to all software development.
When using a programming language, it’s not a bad idea to follow some of the best practices that already exists. PEAR is a large PHP project repository. Most of the up-to-date packages there follow strict directory and file structures along with a set of coding standards. The classes use namespace alike names where each nested namespace is separated with an underscore. These classes are then placed in files named after the last part of the class name, in a directory hierarchy where each directory is named after each part of the namespace.
As an example, the class “Datafeel_Util_URL” is defined in the file “URL.php” under the directories “Datafeel/Util”.
If you have multiple projects that requires the same functionality, you keep all your files and directories under a single path, which you add to the PHP include path configuration parameter. If you create a PEAR package of your project, you can install it globally on your system, and PHP will most likely be able to find your files without changing the include path. Please note that setting up and creating PEAR packages can take some time if you haven’t done it before. Unless you have special needs, such as releasing the project on PEAR, you can happily change the include path and you are good to go.
I have been working on functionality for two WordPress sites lately, and those two sites require some of the same functionality. I started out by just copying the code from the first project to the second, but then all the hard work begins. I decide to rewrite the configuration handler, then add a new web service and fix some bugs related to file uploads. I think it’s hard to keep the plugins from the two projects in sync. Imagine if I had three projects, or ten…