Quality Code and Bloat are two topics that I see a lot of developers either discussing and/or mentioning on the landing pages of their project pages.
I think the conversation around quality code is something that should always be happening. We should always be aiming to get better at what we’re doing, there is always someone who can help us, and there is always someone we can help.
It’s not that I think bloat is something we should accept, nor is it something that I think we should settle for in our projects (or those to which we contribute for that matter). But does it have as an objective definition as quality code?
It’s important to define clearly quality code and bloat as it relates to you, your team, and the solutions you’re providing for others. And I think this is true if you’re working for yourself, in a shop, for an agency, or even as a hobby and you’re building solutions for other people.
How I Define “Quality Code and Bloat”
Though I think the first part of this post was probably enough, it leaves a lack of clarity around how I tend to view both quality code and bloat in the projects that I work on for others and those I work on for myself.
So, naturally, I thought I’d share a little bit more.
When I’m working on projects for others, they generally consist of what you’d expect out of a WordPress project:
- CSS (more specifically, Sass)
So when I’m working on a project, I actively work to make sure the code I’m writing adheres to these standards. This also includes code comments and so on.
This ensures that the code is not only up to what is expected of a WordPress project but that anyone who comes along to read the code or work on the code later knows what’s happening with it.
I find that bloat is a little harder to define. As far as WordPress is concerned, I’ve seen it discussed in a number of ways (all of which may be correct, some of which may be correct, or some of which may not be correct at all:
- Files that aren’t used,
- Too many functions,
- Focus on backward compatibility,
- Not enough focus on backward compatibility,
- Lack of documentation,
- Too many comments,
- …and so on.
For whatever it’s worth, I do think that there are some definitions that make sense (and others that don’t), but that’s beside the point that I’m trying to make. For me, it’s a bit relative.
I know you can script all of that to be removed during the build and deployment or packaging process, but one aspect of open source is that it helps others learn from the code you write (assuming that the code has a level of quality, right? :).
So when it’s a few kilobytes, the file is never served, and it has the potential to help someone else learn, I figure why not?
There’s More To This
It’s possible to take this further with tools like Scrutinizer and Travis CI for continuous integration. They are things that I don’t mean to gloss over, either.
The point isn’t about having the ultimate set of tools, though.
It’s about defining quality code and bloat in the projects you’re working on and making decisions as to what you will and won’t accept when it comes to the code that you release for others to use.
Quality Code and Bloat in WordPress Projects was written by Tom. For more information about WordPress, development, and resources then visit Tom McFarlin’s blog.
Read more here:: Quality Code and Bloat in WordPress Projects