5 “Saintly” Practices that All WordPress Developers Should Strive For

Here on Wptuts+, we talk a lot about the ‘how’ and less about the ‘why.’ Of course, we are a tutorial site, so that’s the goal, right? Well, as a followup to last month’s article on the “Cardinal Sins of WordPress Plugin Development“, today we’re going to look at a few practices that, if every developer followed, would make the world a better place (well, at least our world!).

Last month, we took a look at several things to avoid when working with WordPress Development. Based on the response – which was stellar – we decided to take a look at several saint-like qualities of WordPress Developers.

Of course, the whole title is a bit tongue-in-cheek but the points mentioned throughout the article are not! Strive for the following qualities in your WordPress Development and you’ll notice that they pay off in dividends not only in your development skill but in giving back to the WordPress Community at large.

Saintly Practice 01: Follow Programming Guidelines

Thou shalt follow the codex… Ok, kidding aside, it’s there for a reason though!

For anyone that has worked in WordPress development for an extended amount of time, it’s likely that your code has become more and more standardized over time. By that, I mean that your earlier projects were considered ‘done’ whenever the theme or plugin simply worked whereas your later projects generally consist of cleaner code and use of best practices.

But what about those who are somewhere in the middle of a WordPress career? You know how to work with WordPress, but lack some of the guidance of other WordPress professionals. Simply put, what’s one of the easiest things that can be done to advance to the next step?

Try the WordPress Coding Standards. This is one of the lowest hanging fruit available in WordPress development – it’s easy to understand, easy to begin enforcing, and can pay off immensely when other people begin to use and improve upon your work.

To be clear, WordPress has no way of truly enforcing programming rules in the projects that are being built on top of it. After all, we’re dealing with interpreted code, an open source platform, and developers that range anywhere from beginner to professional. But if you’re looking to be a better programmer and a respectable member of the WordPress community, following the suggested coding standards are a must – your code will be cleaner, easier to maintain, and able to be understood by the WordPress development-community at large.

Saintly Practice 02: Document Your Code

Documenting your code is about more than casual notes for yourself, it’s about leaving something the community can use.

In software development, there are a variety of opinions on how much to document code. Two of the most polarizing are as follows:

• Leave no comments, let the code be its own documentation
• Comment as many lines of code as possible

Generally speaking, I’m a fan of commenting code. I believe that there is middle ground: Document all functions to explain what they do and comment on any code blocks that may be confusing.

I say this not only for the benefit of developers that may interact with my code, but for myself, too. After all, how many times have you looked back at code from six months ago and thought “what was I thinking?” If you can’t recall what your own code is doing, what hope is there for others that stumble across it?

Still, speaking as someone who has done a significant amount of WordPress Development, I can honestly say that code that has been commented is not only easier to understand but it also saves time simply because I don’t have to guess what the developer was trying to do.

Wouldn’t you rather have people being thankful that you explained your code rather than cursing it while trying to figure out how it works?

Saintly Practice 03: Use The WordPress Unit Test

The Theme Unit test is about unifying your own coding approach with the content that all WordPress users have come to expect.

If you’re creating WordPress Themes or working on a plugin that works directly with posts, pages, comments, or any similar attributes, it is considered to be a best practice to test it against all types of content. After all, if you’re only testing the intended case of your project, then you’re only half-way testing your work – users are going to hit edge cases and you want to make sure that you’ve properly handled them!

Enter the WordPress Theme Unit Test. This is a WordPress export file provided by the WordPress Development Team for us to use in our work. Specifically, it contains a variety of posts, post-types, pages, comments, trackbacks, categories, etc. that we can import into our local installation to use for testing our work.

Similar to the Programming Guidelines mentioned above, this is one of the most powerful tools available to us as developers – it saves us from having to create any test content, helps us to evaluate out work, and provides a solid use case for how our work will handle legitimate user input.

Saintly Practice 04: Debug, Log, Review, Repeat

When creating themes and/or plugins, there are a number of utilities that can help ensure you’re providing the most robust code possible. In addition to using the WordPress Unit Test, the following tools can help identify problematic areas in your code – be it WordPress-specific code, markup, database calls, etc:

• WP_DEBUG is a setting located in the wp-config.php file of your WordPress installation. While doing any development work, I always make sure this setting is set to true. It will render any warnings or errors to the screen generated while running your code.

• Theme Check and Plugin Check are two plugins that are designed to ensure that your theme or plugin follow WordPress Development Standards. Specifically, the plugins evaluate your code against the WordPress review standards. Each provides clear warnings, errors, and general information about your code.

• Debogger is a simple plugin that grabs all WordPress debug data and prints it out in the footer of local installation. It provides a clear, well-formatted display of any debug data generated while your code was executing. For those that care about W3C validation, Debogger also prints out validation information.

Though they’ve not always been part of my toolbox, I make sure these are configured, installed, and running each time I do any type of WordPress Development work. They are incredibly easy to use and provide significant value for the amount of effort it takes to set them up.

Saintly Practice 05: Avoid Deprecated Functions

One of the challenges of working with a platform like WordPress is that it is constantly evolving. For the most part, the WordPress Development Team does a killer job at maintaining their API but, like any good piece of software, certain functions and aspects of the API are going to fall out of date. As such, it’s important for us to make sure that our code stays up to date with the platform.

Though it’s possible to continually pour over the Codex to track deprecated calls, it’s much easier to use the Log Deprecated Notices plugin. Similar to the Theme Check and Plugin Check tools mentioned above, Log Deprecated Calls, once activated, will log any API calls that your theme or plugin makes and then offers any alternatives that would bring your code up to date.

Working with WordPress – or any platform, programming language, or technology for that matter – is a never-ending venture. You’re never going to be fully “there.” There’s only room to improve. Just as there are a number of cardinal sins to avoid, these are a few saint-like qualities to pursue.

This list is not exhaustive – add to it in the comments!