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.
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
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
- 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?
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 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.
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.