Question

I am considering different starter themes such as _s and roots. Roots looks very good, especially its sass fork. Anyway, there's one thing that concerns me. It seems like Roots doesn't follow the WordPress coding standards of themes and plugins. What standard do I then follow if I want to use Roots as a starter theme?

Was it helpful?

Solution

This is a very subjective question — though a very good and interesting one, and I'll try to provide my personal view on this.

In general, you should always try to adhere to the WordPress Coding Standards. The only exception to this is when you're changing existing code. Basically, when you're editing an existing "product" (e.g. a plugin or theme), you should use the coding standards the product follows. So, in your case you should adhere to the coding standards of the theme.

Even though this differentiation might seem quite black-and-white, it isn't. There's a lot of grey areas to consider. I'll try to cover a few of those, but let me first try to give a set of basic rules:

  1. If you're not changing a product but building a new one or extending an existing one, use the WordPress coding standards.
  2. If you're changing code in WordPress core, use the WordPress coding standards (even though the additional code might not adhere to them).
  3. If you're changing a product and the code is readable and consistent in formatting, use the original product's coding standards.

In general, the most important thing of coding standards is to keep your code readable. So, when deciding whether you're going to use the original coding standards or the WordPress coding standards, ask yourself the question: what makes the code in this product as a whole more readable, using the original or WordPress coding standards?

Coding standards for child themes

This isn't actually a grey area, but it's an interesting point to clarify: when extending a product (so not changing but really extending), you're providing an additional product dependent on an existing product. This is a separate product, and you should adhere to the WordPress coding standards.

Ridiculous coding standards

If you're changing a product and it has ridiculous coding standards (e.g. coding standards that severely damage code readability), you should opt for using the WordPress coding standards.

Inconsistent coding standards

If the original product doesn't seem to be incosistent in adhering to a particular set of coding standards, you should use the WordPress coding standards for your own, new code.

OTHER TIPS

Roots adheres to its own conventions with a bit less spacing and 2 space indentation compared to WP's 1 tab indentation

Here is what the codex say about indentations

Your indentation should always reflect logical structure. Use real tabs and not spaces, as this allows the most flexibility across clients.

Exception: if you have a block of code that would be more readable if things are aligned, use spaces:

This is not a matter of sticking to coding standards or not. Always remember, readability in code is very very important, and the coding standards makes provision for this.

On your question, the Roots theme are still doing things within the coding standards. I would also think that such a successful theme would not risk their reputation to cross the line. Stick with what Roots offer you, they are within coding standards, so you should keep to their structure for readability

References:

EDIT

This question has recieved close votes as "primarily opion based" which might be correctly so, but is sicking to coding standards really primarily opion based?

As I've pointed out by using the references, the codex clearly states the coding standards you should be using, what the exceptions are to the rule, how the standards should be applied in practice and examples on how to implement these standards.

I really think that this whole exercise comes down to reading and understanding what is said it those pages in the codex.

Licensed under: CC-BY-SA with attribution
Not affiliated with wordpress.stackexchange
scroll top