Does WordPress Encourage Poor Programming?

If you hang around any group of programmers long enough, you’re bound to get into a discussion as to which language is currently the best language and why that’s the case.

Well. Then again. Maybe not.

I’d say this is true is some cases, but I’d venture to say that if you’re hanging around a group who has been at it for quite some time (read: at least a decade or so), you’re going to have discussions as to what features of what languages are nicer in contrast to features of other languages.

A more mature discussion, right? At least a little.

But then you take this one step further: You sit and chat with a group of people who have been working on the same platform or framework for a while and you may find yourself in a discussion about what features of a given framework has that are better than its alternatives..

Perhaps a better way of putting it is: You may end up discussing why one language, framework, or set of tools encourages better programming practices than any other given set of languages, frameworks or tools.

You know you’ve been there when you can quickly list off several reasons, say, Python programmers prefer white space, Rubyists prefer unit testing, Rails developers appreciate MVC, jQuery developers like method chaining, JavaScript programmers love the prototypal inheritance, and Smalltalk programmers love how few of them exist (I kid, I kid).

On a more serious note, there’s no shying away from the fact that people either love or hate PHP. Sure, there’s middle ground but there’s no fun in taking a stance there so you don’t read many articles on people simply saying “Yeah, I think PHP’s okay.” But when it’s used in the context of another framework like CakePHP or Laravel, then you’re likely to find something different.

So ultimately, I think it’s worth asking the question, does WordPress encourage strong or poor programming practices?

WordPress Encourages Poor Programming?

Normally, with these types of posts, I think I – and others, maybe – would spend a few paragraphs building up to our ultimate conclusion, but I’m not going to waste time doing that.

Straight up, I think that it’s a false dilemma.

It Is More Than One Language

First, WordPress is obviously written in not only a combination of languages, but a combination of libraries, as well. Aside from PHP, HTML, CSS, and JavaScript (and SQL if you want to include communicating with the database), you’ve also got jQuery, Backbone, Sass, various PHP utilities (that offer their own APIs), and so on.

Most of these languages have their own way of doing things. For example:

  • HTML has rules about, say, block-level elements being located within inline elements
  • jQuery has rules about writing plugins and handling method chaining
  • JavaScript has rules for managing the properties of existing prototypes
  • Sass has rules about mixins
  • PHP has no rules (I kid, again. Sort of ;)
  • SQL has a formal set of rules that provides a relatively limited set of ways to retrieve data
  • …and so on and so forth

But here’s the the thing: Do you need to know all rules of all of the above before beginning to build things for WordPress?

Similarly, do you need to know MSIL, C++, or the instruction set of the processor to write .NET? Do you need to know enough about lower level code to understand how Java is compiled into bytecode, and that bytecode is managed by an interpreter?

No.

There Is Always a “But…”

But knowing some of the foundational rules of the languages that you’re using can certainly enhance your ability as a programmer. It can help lead to writing more efficient code, more readable code, and more maintainable code.

Of course, you can take it too far, too: If you’re extremely knowledgeable in a language, you can end up writing some really clever code that may be really efficient but may be much more difficult for the average programmer.

And it works in both directions: If you’re not accomplished enough, you may end up writing some extremely verbose code, and extremely verbose code ends up being less malleable or more resistant to change.

So there’s a balance to be struck. Personally, I love that the WordPress Coding Standards supports this:

In general, readability is more important than cleverness or brevity.

I know – that alone sound like I’m saying that WordPress does encourage positive programming habits; however, that’s generalizing based on a small statement in a much wider set of documentation on which I digress.

For now, at least.

What Brought This About?

Ultimately, what raised this question is the usual back and forth that shows up every few months from someone involved with the WordPress economy in some way (this could be a few months of experience, this could be years of experience – it doesn’t matter).

That is to say that for anyone who has been around WordPress long enough, you know that every few months someone raises an opinion (and I’m not saying it’s valid or invalid in this post) about the quality of code that makes up WordPress, and then the quality of the code of the work that’s built on top of WordPress.

In some cases, people seem to reason that:

  • WordPress uses poor coding practices,
  • Themes and plugins are built for WordPress,
  • Therefore, themes and plugins use poor coding practices.

This is a bit of a tangent, but WordPress isn’t fully composed of poor coding practices. In fact, there are some really mature aspects to the application. Furthermore, depending on what your background is, you may think that the use of object-oriented programming and use of design patterns is high quality whereas others think that the use of procedural code is a bit more elegant.

Whatever your flavor, it’s there.

Again, this isn’t to say that there aren’t parts that don’t need to be refactored, cleaned up, removed, or whatever else – I don’t know anyone arguing that, but this is not a conversation about that, nor is it a conversation about the challenges of backwards compatibility or anything of that nature.

So anyway, back to the main idea: I don’t believe that WordPress itself can encourage positive programming practices anymore than it can encourage poor programming practices.

That is to say that if you want to get something working and you want it working within WordPress, then you can make it happen if not by following the WordPress API, Coding Standards, and all of that good stuff, then by sheer force of will through the use of circumventing the entire system by taking advantage of facilities offered by the languages that compose the application.

  • You don’t want to deal with caching in the way that WordPress does with transients? Fine – use your own PHP library.
  • You’d rather create your own database table with a custom set of queries to read and write data? Totally doable.
  • You want to manipulate the dashboard DOM via Ajax without using jQuery and/or the Heartbeat API? Go for it.
  • You’d rather avoid using object-oriented design patterns in your plugins, or taking advantage of the event-driven pattern implemented via the core application? It’s possible.

So what?

So the point is that it’s not so much about encouraging good programming practices over bad ones (because I believe that every language, framework, foundation, and tooling allows varying degrees of that), but it’s about the quality of the work that you do within the context of your environment.

Yes, you can write absolutely terrible code that powers a project on top of WordPress. But you can do the same thing within, say, a Rails application. And although the Rails programmers will say that their “convention over configuration” philosophy prevents this, then they’re kidding themselves.

Programmers are notorious for making things work regardless of how the solution is architected.

My Point?

It’s that it’s not so much about what languages or tools you opt to use, but how you pursue excellence in the environment with which you’re working the most.

Sure, you can hop from platform to platform learning how to write code in each platform and making things happen, but to be truly great – to be world-class – at what you’re doing, you’ve got to know the platform inside and out, and you’ve got to know how to leverage all of the tools that are at your disposal to their maximum potential.

I’m certainly not there (nor do I claim to be), but I do know that I want to be there, and that I’m working to get there.

So rather than worrying about whether or not WordPress – or Laravel or .NET or Java or Rails – promotes good programming practices, I think we need to look at ourselves and decide if we’re doing all we can to ensure that we’re designing systems and writing code that follows good programming practices.

And if we’re not, then we continue to learn from our mistakes, refine our work, and move forward with what we’re doing.  You’re far more likely to hear me talking about the things that we can be doing to improve ourselves as programmers than you are to hear me talking about which languages and tools promote the best practices.

Because we can do some damage regardless of what we’re using.

20 Replies to “Does WordPress Encourage Poor Programming?”

    1. Please don’t take what I’m about to ask as sarcasm – it’s a genuine question (and tone is sometimes hard to convey on the web :). Plus, this is something that I really enjoy discussion.

      Is this a loaded question, or are you genuinely interested in what does constitute poor programming?

      Knowing you and previous comments you’ve left, I’m sure it’s a valid question, but I just want to make sure before I go on too much more ;).

      1. Understandable! I feel as if I’ve been stuck programming at an intermediate skill for about 4 years. Coincidentally, this is also around the time I started picking up WordPress. Which makes me also wonder, “Does WordPress Encourage Poor Programming?”

        1. Hi Rusty,

          I relate to your concerns about being stuck at an intermediate level.

          For me, the greatest boon to my coding has been two things. 1) Contributing to high quality WordPress plugins. 2) Showing your code to people who are better than you.

          For me, I started contributing patches to Shopp (a WordPress e-commerce plugin) which forced me to start thinking about my code in a larger context, which ultimately greatly improved the quality of all of my code.

          And, I started looking for opportunities to share my code and get it in front of people (like Tom, for example!) and let them tell me where I can improve.

          Hope this helps!

            1. Contributing has been a fear of mine

              Welcome to the club :). We all feel it at some point – in fact, sometimes it may not ever really go away, it’s just minimized :).

              The thing to remember is that you’re getting you’re code in front of people who care about your code and want to improve it, as well as who want to help you get better at what you’re doing.

              Sure, there are negative people out there who can say some pretty lame stuff – and we’ve all experienced it one way or another, I’m sure – but those aren’t the people who are doing the things worth following, anyway.

              It sounds trite, I know, but the point is that I used to be afraid of pushing any code to GitHub for sake of the responses or critiques. Now, I welcome them.

    1. It’s hip to bash WordPress, all the cool kids are doing it.

      Yeah – and it has been for a while. It’s also trendy to use other languages and frameworks.

      It all depends on what you’re trying to build (and for who), so sometimes WordPress is not the right choice, sometimes it is.

      Whatever the case, it – and other languages and tools – are always going to have their critics. It’s frustrating at first, then it just becomes part of the routine ;).

  1. Hi, I can’t agree more.

    Nobody’s perfect. We do some stupid things as developers, me make mistakes, of course we do ! We are not taken seriously by “high PHP skilled dev” and when I say “we” I meant “wordpress developpers”. Some people say it’s not even development… it’s WordPress.

    The only thing that matter is how we can learn from our mistakes and improve ourself to give the best solutions for our clients. I’ve been doing WordPress for 2 years and I do not regret it at all. And you’re perfectly right WordPress is not just about PHP in fact it’s an environnement that’s why I’ve no complex saying I’m a WordPress developer.

    Indeed there are flaws and bad practices and the WordPress core isn’t perfect but it’s powering more than 22% of the web therefore there are A LOT of constraints !

    If you do not want to use good practices, if you do not want to improve yourself nobody can do it for you ! You can be a poor developer trying to use high skilled techniques that would not make you a better programmer.

    PHP itself lacks of consistency so you can build whatever you want the basis remains the same. I’m not saying this as an expert of course, I’m a rookie.

    1. My sentiments exactly! I’m no seasoned expert in any programming language by any means and I’ve put some awful code together for sure, if I look at code I put together a few months ago I know it’s probably not great, if I look at code I put together a few years ago I know it’s poor! But, what I do know is that it’s better to know where you’ve gone wrong and how to do things in a more efficient and standard way – making mistakes is good, knowing that you’ve made mistakes is harder to confront, if you’re willing to progress with standards in mind go for it! If you’re not then that’s poor.

      1. if I look at code I put together a few months ago I know it’s probably not great, if I look at code I put together a few years ago I know it’s poor!

        Such is the nature of writing the code.

        The thing that can give you a complex is what are you going to think of the code you’re writing today? ;).

    2. Nobody’s perfect. We do some stupid things as developers, me make mistakes, of course we do ! We are not taken seriously by “high PHP skilled dev” and when I say “we” I meant “wordpress developpers”. Some people say it’s not even development… it’s WordPress.

      You’re right. People do say that, and that’s okay. The thing is that people’s opinions and perspectives are often limited by what they’ve either experienced directly and through what other people have done.

      If they haven’t seen some of the things that have been done with WordPress, then there’s no way they actually know how far the boundaries can be stretched. And that’s okay. It’s just a shame that people speak so authoritatively about something with which they don’t know.

      Then again, we all do that, right? It’s human nature to some degree.

      And you’re perfectly right WordPress is not just about PHP in fact it’s an environnement that’s why I’ve no complex saying I’m a WordPress developer.

      Exactly. The problem, in my opinion, is how this is received. And this is something that I hope to discuss in a future article.

      PHP itself lacks of consistency so you can build whatever you want the basis remains the same. I’m not saying this as an expert of course, I’m a rookie.

      Few of us are experts. Even those who think they are experts probably aren’t. The people who I’ve found to be true experts would never call themselves that. They’re also eager to help others, respectful, and humble (most of the time ;).

  2. I agree totally, and Ive had this discussion before. WordPress uses a procedural event driven pattern similar to the object oriented observer pattern seen in many frameworks and cms. But the fact that it is procedural doesn’t impose any particular coding convention on theme/plugin developers. Typically wordpress theme code is ugly repetitive and mixes too much php and html BUT this is not by force as a developer can just as easily use a templating framework like twig on top of wp. Ive even seen people use laravel and symfony components in wordpress plugins. I dont care for a few of wordpress’s defaults. For example I think the template hierarchy and file structure is confusing and annoying and i hate having to put so many files in my theme root directory but wordpress provides the means to override this default. Instead i only create empty index.php and style.css so wordpress recognizes my theme and store all other templates in /views directory. Then i use the body class to determine which template to use via template include filter and what not. That being said WordPress gives tons of control to developers that is typically used for evil (bad coding) but can and has been used for good.

    The main problem is… Good is way too subjective. Also when so many developers change the default wordpress conventions in the name of comfort (for example when someone turns wp into an MVC) it is bound to make other developers uncomfortable as they may understand wordpress well, but not twig or the laravel ioc container etc… In that case the meaning of “wordpress developer” starts becoming ambiguous. Its like if i turned a car into a rocketship and brought it to a auto mechanic.

    While freedom is good, so is convention. And lets face it WordPress conventions arent thbe best. Even if wp allows better. Just take a look at thbe 2014. Its LOADED with repeated code

    1. WordPress uses a procedural event driven pattern similar to the object oriented observer pattern seen in many frameworks and cms. But the fact that it is procedural doesn’t impose any particular coding convention on theme/plugin developers.

      Exactly. There are certainly a few constraints that we have to follow (basically as it relates to register or de-registering hooks), but that’s it.

      Because of that and because of the nature of PHP, it can be a bit of wild west when it comes to writing code. Some languages for conventions more than others. That’s cool. PHP doesn’t do that. Sure, there are times where I wish it was a little more structured, but what’s preventing me from just being a more disciplined programmer?

      Good is way too subjective. Also when so many developers change the default wordpress conventions in the name of comfort (for example when someone turns wp into an MVC) it is bound to make other developers uncomfortable as they may understand wordpress well, but not twig or the laravel ioc container etc… In that case the meaning of “wordpress developer” starts becoming ambiguous.

      Yep – and the funny thing is you can implement things such as dependency injection and inversion of control containers within plugins (I suppose you can do it with themes, but I question the need for something like that unless you’re building an app theme ;).

      Anyway, that’s the problem with “WordPress Developer.” Often times, it means that you’re skilled with the application, are familiar with a lot of plugins, and can be trusted to piece together functionality based on selecting themes, plugins, and so on then maintaining the installation.

      That’s sad for those of us who really want to get deeper into development, programming, and doing much cooler things with WordPress.

      1. Anyway, that’s the problem with “WordPress Developer.” Often times, it means that you’re skilled with the application, are familiar with a lot of plugins, and can be trusted to piece together functionality based on selecting themes, plugins, and so on then maintaining the installation.

        I used to be this kinda of “professional” when I started to actually earn money with WordPress but I’ve decided to go deeper to see what it’s like and I see people doing great stuffs with WordPress. In fact WP is more and more a framework for our web and mobile applications. I’ve get the opportunity to do this as full time job and it’s pretty exciting.

        The fact is that most of the time people who say “you can’t do this with WordPress” should say “I don’t konw how to do this with WordPress”, the same people who like to say “that’s impossible”. The same people who like to reinvent the wheel when they do WordPress. It’s like saying “I can’t sail with this plane” => maybe you could use a more specific tool for your very specific task.

        I hear this a lot of time : “it does not scale!” => again very specific need. There’re some way to make it work such as database partition, SQL request optimization, etc. It requires to go deeper and to know exactly what you are using.

        You can’t do interesting things without going deeper. It’s not due to WordPress, that’s the very nature of programming.

  3. I say let the snobs with their bubble pipes keep on blowing their bubbles. I think elitists are usually self-interested in their own brand more than they are interested in the craft.

    Developing for WordPress is one of the best decisions I’ve made financially or otherwise. My code has improved leaps and bounds year over year. And the community is awesome.

    I think it’s good to talk about code quality, and push people to shoot higher while still welcoming in newer devs and designers who are easily intimidated by code and best practices.

    And I think that’s happening naturally. It’s harder to get a plugin into the repo now than say 5 years ago. But that transition has happened without alienating people.

    We’re at 22% now, but I think that number is just the tip of the iceberg. I know so many devs who exclusively develop sites with WordPress. Which is why I have zero interest in what the snobs have to say about it.

    1. Those who have been programming far longer than we have probably look at the things that we – and detractors – say about our environments, tools, languages, etc. and laugh.

      Partially because this isn’t anything new, and partially because things are so much more advanced than they were for generations past.

      I think it’s good to talk about code quality, and push people to shoot higher while still welcoming in newer devs and designers who are easily intimidated by code and best practices.

      Exactly. If for nothing else because we were all there (or are still there :) at some point.

  4. The problem with WordPress is that it makes bad decisions so easy to make, and so hard to unmake.

    WordPress, with its nice neat themes written in glorious PHP, doesn’t care if you insert some code that has nothing to do with site presentation into it. In fact, for a novice programmer who doesn’t know how to roll their own plugins, it can seem like the only solution. It doesn’t help at all that so many forum and blog posts made with instructions to solve this or that problem advocate exactly that.

    I’ve had to develop WordPress for my job for a while now, and so many of the decisions plugin authors have made-some damn prominent ones among them- just leave me scratching my head.

    GravityForms is an example I’ve been wrestling with recently. It bills itself as an “advanced” form-creation tool. It has all these great features, drag-and-drop, CRM, hell even extensions that let you accept credit cards and paypal! So many impressive shiny things and kool buzzwords to get the head of any marketing department just throwing their coins at the screen.

    But then it gets handed off to me, and I’m tasked to code something to leverage the awesomeness. It fought me every step of the way. Firstly, there’s no way to easily and dynamically convert the results of a form submission to simple key-value pairs. You have to hard-code it straight into PHP from automatically assigned, unchangeable numeric IDs, which means you can’t reuse that code you can’t roll something that automatically handles it.

    So many of their own tutorials instruct you to do things like iterating over every single individual form field on every single submission, even ones that don’t use your custom field. If you have fifteen or so custom fields, as I needed, that can lead to a lot of overhead on a small system.

    This is a highly regarded bit of software, something that everyone who uses WordPress is familiar with. It’s such a shame that it sucks so badly.

    I also found out that those special awesome plugins that add cool things like credit card accepting and mail list integration? They have special hooks that had to be hard-coded into the core of the plugin to enable them. That’s insane!

    There’s no way something so limited would’ve ever gotten off the ground in something like Rails. I didn’t have these problems even when I did a stint with ASP a couple of years back.

    I place the blame squarely on the WordPress culture of ignoring best-practices, deriding them as busy-work, when they’re really there to make everyone’s lives easier.

    If I wanted to sleep I’d have never become a programmer. I just wish I was spending my nights coding something I could be proud of.

    1. That is to say that if you want to get something working and you want it working within WordPress, then you can make it happen if not by following the WordPress API, Coding Standards, and all of that good stuff, then by sheer force of will through the use of circumventing the entire system by taking advantage of facilities offered by the languages that compose the application.

      This approach, this philosophy, not only defeats the purpose of using a framework in the first place, but leads to incompatibility, non-portability, things breaking on updates, a whole host of things. It’s far far better to choose a tool that will do everything you need to get a job done in a standardized, agreed-upon, contractually-designed (in the programming sense, not legal) way than to roll some non-standard stuff into your code that you’ll have to come back and completely re-do or abandon entirely some time down the line.

      Sometimes WordPress is the best tool. Sometimes it’s not. What’s harmful is people choosing it despite its weaknesses just because it’s the only thing they’re familiar with.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.