Keeping Your WordPress Coding Clean and Neat

Community Forums Forums Design Tips and Tricks Keeping Your WordPress Coding Clean and Neat

This topic is: not a support question

This topic contains 2 replies, has 2 voices, and was last updated by  Jon Weiss 3 years ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
  • #169

    Jon Weiss

    Below are some snippets from a pretty neat article on Smashing Magazine about WordPress coding. I’d suggest checking out the article and learning a little more about the importance of tidy coding and how it can help you with both design and development of web sites.
    Even if you’re working on a pet project, the format of your code says a lot. And if you’re in a multi-developer environment, it speaks volumes. Code that is well formatted and well thought out shows quality (even if it isn’t good), while chaos begets sloppy programming (even if it is genius).

    Here are but a few reasons to pay attention to the format of your code:

    Well-formed code is easier to maintain. You might know what’s going on today, but what about a year from now? Taking the time to give structure to your work will save you eons of time later on (… well, maybe not eons).
    Other developers do not share your brain, so they won’t understand your chaotic code, or they would need a long time to untangle it. Ensuring as little friction in communication as possible is in the project’s best interest, and this can be facilitated by standards-compliant formatting.
    Slightly less importantly, someone who is learning to program should be able to visit a website and learn something by looking at the source code. Standards usually have an inherent logic, so an onlooker would be able to figure out what’s going on. Adhering to standards could help a lot of budding developers learn programming the right way from day one.
    In many cases, good formatting helps maintainability. Many standards require you to space out if statements and other blocks of code. Not crowding the code together will make an “Error on line 267” message much easier to fix.

    Line breaks

    WordPress’ documentation says nothing in particular about line breaks, but adding a line break after most statements is common practice. Variable definitions, items and so on should be on separate lines.


    Indent code to show a logical structure. The goal here is readability, so any indentation that makes the code more readable is a good practice. Use tabs at the beginning of lines, and use spaces for mid-line indentation.

    Space usage

    Remove all trailing spaces from line endings. Empty lines with tabbed or non-breaking spaces is also common — remove these as well. But use spaces to make your code readable, most commonly within parentheses. Insert a break after an opening brace and before a closing brace, except when typecasting.
    Consistent styling is just as important in CSS as in PHP and HTML. When a user wants to change a small detail in your theme, they will inevitably end up in a CSS file. Thus, the CSS could be the most visible code that you write. The “CSS Standards” document is a “rough draft.” Most of what’s there is probably there to stay, but as stated on the page itself, it is all subject to change.

    Follow the draft closely. If something changes, you’ll still be up to speed on most of the guidelines; and if your existing CSS code doesn’t adhere to it 100%, the reason will be understandable.

    — View the full article here.

    • This topic was modified 3 years ago by  Jon Weiss.
    • This topic was modified 3 years ago by  Jon Weiss.

    Gary Jones

    As much as an I’m an advocate for following the coding standards, they do leave some holes within common examples of code, which means that inconsistency is introduced as different coders fill those holes with their own preferences. Multi-line function call arguments is an obvious one. It also doesn’t cover items in PHP that are introduced in a version of PHP later than the required minimum, which again leaves developers who make the minimum requirement of their code to be 5.3 or later end up with inconsistent coding.

    My advice, would be to have PSR-2 as the common coding standard, except for where the WordPress Coding Standards explicitly define how the code should be formatted. A lot of packages and libraries outside of WordPress are tending towards PSR-0, PSR-1 and some to PSR-2, so for the sake of having those holes filled with someing, it makes sense to use a common modern standard from outside of WordPress.

    Changes in Genesis 2.1 – the ultimate guide to every single change in Genesis Framework 2.1, 2.1.1 and 2.1.2 (all 90 of them!) | @GaryJ


    Jon Weiss

    I agree Gary. Although there are definitely some things mentioned in the article that I’d say to follow, this was more intended for some of the newer coders / people looking for general tips. But I’d definitely recommend following the PSR-2 Standards as well.

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.