Our code in WordPress plugins and themes should follow some basic standards. Here are a few simple tips to make your code more aligned with the standards of the core project.

Prefix everything

Nacin said it best. Prefix everything. Prefix your functions. Prefix your classes. Prefix anything that has even a little bit of a chance to conflict with core or other themes and plugins.

My default for a personal snippet is krogs_some_function(). With client sites I often prefix with the site initials or name, making sure it’s fairly unique.

edit: It’s worth reiterating based on some Twitter feedback: prefix everything means prefix everything. Be mindful of your hook names, settings names, or anything that could conflict. That said, if you prefix your Class, you don’t need to prefix the methods within, as those are unique to the class itself, which is prefixed.

Return vs echo

WordPress core typically follows a general convention that if the function has output, then two functions should be made available. One function returns data, and another is a wrapper of the first and echoes the data. Sometimes the version that echoes the data could also provide additional filters that the returned version does not. A simple example of this method in practice is WordPress’ get_background_image() and background_image().

Your project code could gain significant flexibility for other developers if it utilizes a similar syntax and format. Few things are as annoying as finding the perfect function in a project that you could use, only to realize it doesn’t output the data the way you want.

Naming conventions

As noted in the core handbook PHP coding standards, WordPress uses lowercase and underscores for PHP functions, and capitalization and underscores for class names. In JavaScript, use camelCase with TitleCase constructors.

For filenames, whether CSS, PHP, or JavaScript, it’s standard practice to name files with lowercase words separated by hyphen.

Braces and spaces

I’ll finish with a couple of items that I know some programmers really don’t like. WordPress recommends using braces for most non-template if / else statements. I like to go one further, and recommend that even for a one-liner, we should be using opening and closing braces for if statements:

if ( krogs_condition ) {
	krogs_action();
}

This may seem ridiculous, but in my opinion it provides just a tiny bit of extra clarity for those that follow behind you.

For spaces, the coding standards recommend spaces, “after commas, and on both sides of logical, comparison, string and assignment operators.” This is one standard that I feel is really not followed closely by a lot of developers.

In summary

Most of what I’ve shared here is straight from the WordPress Core Handbook. Coding standards for PHP, CSS, HTML, and JavaScript are available there, plus and tons of other useful information.

I highly recommend you review the coding standards and see how you could be making some easy to implement changes to improve your code. Oh, and if you see code snippets in the Codex that aren’t following the WordPress coding standards (and there are many), go ahead and edit them to make those snippets better.