At this point, it’s relatively easy to find a generator to do almost anything you want with WordPress. In fact, you can assemble an entire theme with custom post types, taxonomies, and options all without actually writing any code.
But you know what I’m talking about – generators are small web-based tools that are used to, er, generate code for you based on a couple of inputs that you specify on an interface.
Off the top of my head, I can think of…
- Generators for custom post types
- Options frameworks for easily creating settings pages
- Generators for taxonomies
- Custom theme generators
- …and more.
Don’t get me wrong, I think that these tools have their place in the development space (in fact, my boilerplates have even been converted to generators!).
But as a profesional developer and someone who cares about writing quality code tailored exactly for the problem at hand and as someone who wants to create the highest-quality products that I can, I dislike WordPress generators.
And there are a number of reasons why I don’t use them:
- WordPress Coding Standards. These are defined standards that are intended to be used in all WordPress-based projects. The ultimate goal is to provide the right way to write code for WordPress. I’d even go as far as to say that when developers follow coding standards it looks as if code is written by the same person. Without testing every single generator and every permutation of settings, there’s no way to know that the generated code is up to standard.
- Debugging Sucks. We spend enough of our time debugging code and that’s why we write our own, but if something goes wrong with a product that you’ve released that is based on code provided by a generator, you have a layer of complexity through which to trudge in order to narrow down the problem. So it’s not enough to find bugs in your own code, it’s now a matter of understanding what the generated code is doing, the key/value pairs it’s creating, how it’s serializing its data to the database, and then determining how to resolve a problem that’s a result of code you didn’t even write.
- You’re Shielded. If you really want to become a professional developer – regardless of if it is for themes or plugins – then there’s a period through which you have to suffer while learning the various API’s. Be it the Options API, the Settings API, the Transients API, the Plugins API, or whatever it is that you’re trying to pursue, you’re never going to learn it if you’re letting an automated tool generate the code.
- Database Ignorance. In additional to generating questionable code, we – as developers – should be responsible for having a holistic view of the project that we’re working on. This includes understanding how the data is serialized in the database, being responsible and validating, sanitizing, and generally cleaning up the database when we’re doing. We need to be wise with our resources. Again, without spending additional time with the generators, it’s difficult to know how much we’re cluttering our customer’s databases.
I view software engineering as a craft. It’s a practice of identifying a problem, architecting a solution, and then implementing it using code. These are principles that are completely agnostic to what platform on which you’re working.
Sure, code you wrote two years ago probably sucks and code you write today will suck in a few months. But the point is that you’re writing code, you’re refining your craft, and you’re improving yourself.
Generators rob you of that.
With that said, I do believe that these frameworks and generators have their place in WordPress development. I think they are great tools to use when rapidly prototyping a project to make sure the core business problem is understood. I also think they are fine for putting together a quick demo, but you have to strike that balance – if you’re not careful, you’re piecemealing together a product and that’s not quality software development.
You can always default “to each his own,” but I call into question the integrity of anyone that brands themselves a developer but pushes products that have been assembled by nothing more than purely generated code.
Use generators when appropriate – for demos and prototypes, not products.