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.

Quality Code

When I’m working on projects for others, they generally consist of what you’d expect out of a WordPress project:

  • WordPress
  • PHP
  • JavaScript (more often than not, jQuery)
  • CSS (more specifically, Sass)
  • HTML

And, as I’ve discussed many times before, WordPress provides coding standards for PHP, JavaScript, and HTML. It’s possible to even evaluate your code against these rules before shipping it.

Quality Code and Bloat

No issues from the CodeSniffer. :)

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.

Bloat

When it comes to creating “production-ready” files, I use minification and lint tools to help with both JavaScript and CSS to make sure that the code that’s actually served to the browser is as small as possible.

CodeKit and a WordPress Plugin

Using CodeKit to manage bloat in a WordPress plugin.

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.

By that, I mean if you’re including both your un-minified JavaScript files and your minified JavaScript files, one may argue that it’s bloat. Then again, we’re talking about a few kilobytes some of which aren’t even sent across the wire.

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.

Category:
Articles
Tags:
,

Join the conversation! 5 Comments

  1. Hi Tom,

    This is a very interesting post; especially for people (like me) who either spend time working with products that other developers have created, or are trying to create their own WordPress templates and extensions.

    Perhaps two ways of looking at bloat (as far as WordPress is concerned) would be either:

    a) A feature or component that adversely affects end-user or middle-user efficiency and performance. In some situations this would be components or features that affect website performance or users, and that may have been introduced by the product developer

    or

    b) A feature or component that distracts (or detracts) from the primary purpose for which it was intended; e.g. template components that are difficult to appreciate or use because they have too many controls.

    I know the above is a broad sweep, and maybe it is more ambiguous than useful, but I think this would be one approach to evaluate bloat.

    So, given the above, it is quite possible that some overly engineered WordPress components may be considered “bloatful”, even though they may have been developed with the best of intentions.

    For WordPress solutions (themes or extensions), one way to avoid bloat in my opinion might be to componentise features, and allow middle-users, and end-users to plug and play each component as appropriate.

    I believe this is possible with WordPress components; just that additional planning will be required before developing components.

    An example of this would be the componentised version of the underscores theme (or similar).

    A lot of themes and extensions either don’t do this componentisation yet, or if they do, its quite difficult to choose sub-components without losing the core feature of the product.

    “Bloatful” components make it difficult for end-users to focus their efforts on high priority website activities, and they also introduce additional risk into down-level WordPress projects; which is why this post is very important, and should be discussed more by people who “make” or “use” WordPress.

    Thanks

    CJ

  2. Perhaps you put this under Code Quality but what about making it ez for others to configure / change the “settings” of your code. I mean, if all the basic “stuff” were in a class and that class was wrapped with if class_exists() then someone else would be able to preload their own version of that class prior, and thus override that original class. This would be especially great for views when you just need to trick something out and you don’t want to have to fork the whole plugin.

    It’s a shame WP hasn’t adopted a standard for such things. Yet?

    • Perhaps you put this under Code Quality but what about making it ez for others to configure / change the “settings” of your code.

      I think this depends. If you’re using a lot of constants or something like that (ala wp-config.php) then that makes total sense.

      If, on the other hand, you’re using a lot of OOP, then you’re classes, attributes, and functions should all be well-documented so others can trace the code relatively easily and then make changes as necessary. Perhaps the first thing that comes to mind is creating a class interface and then programming to that. Then you can implement the interface, extend the classes, etc.

      I mean, if all the basic “stuff” were in a class and that class was wrapped with if class_exists() then someone else would be able to preload their own version of that class prior, and thus override that original class.

      This is more of a butchering of OOP, in my opinion. I think class_exists checks are good in large PHP projects like WordPress especially because we don’t know how generic a class may be named. If we use things like namespaces, we can help with that but that’s also contingent upon PHP versions so, you know, there’s that.

      But programming against an interface versus an implementation can do a lot more to benefit us that writing large conditional for class checks.

  3. Bloat has come to mean client-side more than server-side.

    Backends are so fast now it’s rarely an issue, unless there’s an actual delay with an API you have some seriously buggy code.

    I made the mistake of always checking delivery with Chrome emulation instead of on a mobile device. Chrome will always be maximally efficient since you’re usually testing on a desktop with high CPU power and broadband. But switching to an actual device shows all kinds of delay.

    And native apps aren’t any better. In fact, web apps often out-perform native apps.

    • Bloat has come to mean client-side more than server-side.

      In some cases, sure, but at the same time we have a lot of SPAs that are largely client-side code making calls to the server-side and they aren’t that bad, IMHO.

      But that depends on the quality of the code going into the app.

      Backends are so fast now it’s rarely an issue, unless there’s an actual delay with an API you have some seriously buggy code.

      Agreed.

      I made the mistake of always checking delivery with Chrome emulation instead of on a mobile device. Chrome will always be maximally efficient since you’re usually testing on a desktop with high CPU power and broadband. But switching to an actual device shows all kinds of delay.

      Yeah, :sigh: this is kind of a tedious exercise when it comes to deploying, testing, deploying, testing, etc. with certain projects.

      As long as expectations are managed, though, customers should be okay. It’s just the tedious nature of our job.

      And native apps aren’t any better. In fact, web apps often out-perform native apps.

      To me, this depends on what the native app is doing and where it’s calling. If it’s 100% on the device, then it may not be so bad. If it’s a hybrid, then it might be bad.

      If it’s a web app running in a wrapper then I think it all depends on a number of factors.

Leave a Reply

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