The WordPress Coding Standards: An Introduction

When it comes to building WordPress-based products, we’re somewhat cursed (or blessed, depending on how you see it), with a double-edged sword: Because WordPress is written in PHP, it’s relatively easy to get WordPress – or the project itself – to do whatever it is we want to do all the while avoiding best practices.

But this raises the question: What’s the point of an API or formal coding standards if we’re simply going to ignore them?

We’ve written quite a bit about the WordPress APIs in previous articles, and we’ve touched on the WordPress Coding Standards, but we’ve never really taken a deep dive into the coding standards, understanding each aspect of them, and why they matter.

So in this series, we’re going to be doing just that.

Why Bother With Coding Standards?

Before taking a look at everything that we’re going to be covering, I think it’s important to understand why coding standards even matter.

WordPress is widely used by a lot of people using a lot of sites. There’s a lot of code being employed out there that’s all built on top of the core application. This means that there are developers and designers who are working to maintain those code bases.

The challenge comes when the person who didn’t originally write the code is stuck with improving, managing, and fixing bugs for the project. Let’s say that the first person didn’t follow the coding standards, but the person who is now maintaining the code is used to following best practices.

They now have to deal with code that looks nothing like what WordPress code should look like.

And that’s really the crux of the matter: The code that makes up our themes, our plugins, and in our applications should ideally look like a single developer wrote the code.

That’s what coding standards enforce.

Unfortunately, standards are either ignored or they aren’t evangelized enough despite the fact they are well-documented. That’s where this series of articles comes into play: We’re going to be looking at each of the standards in-depth to evangelize, to understand, and to encourage one another to begin doing a better job.

A Look at the Coding Standards

This series is going to include seven article in addition to this introductory piece.

Here’s where we are headed with this particular series:

Naming Conventions and Function Arguments – We’ll take a look at how we should name our variables, methods, and classes such that they are clear, easy to understand, and follow for ourselves and other developers.

The Use of Single Quotes and Double Quotes – Single quotes and double-quotes result in different behavior in PHP and there is a time and a place for when to use which in WordPress. In this article, we’ll take a look at examples of each and the rationale behind what we’re doing.

Indentation, Space Usage, and Trailing Spaces – White space places a big part in writing WordPress-based code. This article is going to explore the reasons why indentation and space matter as well as when to use tabs and when to use spaces.

Brace Style, Regular Expressions, and PHP Tags – Different C-style languages use different syntax. This article will examine the proper way to place braces in your WordPress-based code. We’re also going to examine the proper way to include regular expressions, as well as some of the gotchas and best practices as it relates to using PHP tags.

The Ternary Operator and Yoda Conditions – Conditional statements are a corner stone of programming and they are used liberally throughout WordPress. PHP offers a shortcut for if/else statements, and WordPress opts to evaluate conditionals differently than what other languages often support. Here, we’ll take a look at all of the above.

Database Queries and Formatting SQL Queries – There’s a full API for running queries against the WordPress database, but there are also ways to run raw SQL. If you ever need to go that route, there’s a right way to do it. This article will take a look at exactly that.

Bringing It All Together – Finally, we’re going to summarize everything that we’ve discussed throughout the series to make sure that we’re all on the same page, and to urge us to move forward with doing a better job of adhering to the standards.

Conclusion

When it comes to blogging, it’s often assumed that the author is an expert in the topic at hand, but the truth is although I firmly believe that we should follow the coding standards and that I try to adhere to them to the best of my ability, I’m learning things each week.

I’ve violated the coding standards plenty of times, and I’m sure some of you have, as well.

The point of this series is to walk through the standards together so that we may all come out as better developers once we’re done.