On Coding Style
You can probably guess from the post frequency on my site that I’m not a fan of blogging. When I’m in developer mode, I’m more interested in creating nifty bits of code that conform to my artistic sensibilities and possibly have the side effect of making my work easier.
The same goes for releasing things. I’ve got completed, documented, portfolio- quality work just sitting around on my GitHub collecting dust. The bigger the project, the more work goes into the details of releasing it. I’ve never really been very interested in maintaining my geek cred, which means that when it comes to deciding when to give my projects their final nudge out the door, I usually opt for “tomorrow”.
The problem is compounded when taking into account the style of my work. Over the past few years, as I’ve gotten proficient enough at coding to develop romantic notions about what the perfect code should look like, I’ve tried a few different extremes.
The Widget Approach
There’s the simplistic approach, which I built my widgets on. Basically, the idea behind that is Mr. Google Coder doesn’t know, or necessarily need to know, the details of how the widget works. He wants to FTP some files to his server so his boss doesn’t fire him.
Judging by the fact that widgets drive the most traffic to my site, I’d say a lot of people are in this category.
I’m not a fan of this style, which is a sort of strange thing to say, considering it’s my own code. When I read the code for RabidRatings, I shudder at the embedded HTML in the JS. The SQL statements in the PHP are a horror show, and don’t get me started on the defined constants at the top instead of a proper configuration strategy.
If I were to implement RabidRatings with a real project, I’d scrap most of the code and work within the context of my project for the right solution. However, as a testament to its effective value to its target audience, I’ve never actually been offered any money to implement the script for a client. As a completely modular, isolated application, it just works out of the box.
Which isn’t to say it’s perfect, not by any means. There are a lot of adaptations of RabidRatings written by other coders, most of them integrations with server-side frameworks. But since I opted for a “uglier”,1 more modular approach, the frontend and backend can be used independently of each other, 2 which is what makes the adaptations possible.
The point is, when the goal is to code myself out the equation, how I feel about working with the code is irrelevant. If I do the job right, I’ll never have to touch the files beyond basic maintenance.
Now, you might notice that I’m not exactly adding new widgets to my site every week, despite their popularity.
The “Rabid” Approach
Anyone who’s clicked on my GitHub link might have noticed a couple of projects sitting around there. RabidCore and RabidRunner. RabidCore has been sitting there for almost a year now, and RabidRunner isn’t getting any younger, either.
From an outsider’s perspective, utilizing the normal metrics of open source project health, it looks like I got to 90% completion on those projects and then got bored, in proper developer fashion. In reality, I finished the projects, had great success utilizing them in client work, continue to use them whenever the opportunity comes up, and would recommend them to others. Hell, I consider those two projects to be my crowning achievement as a developer.
So why haven’t I talked about them publicly? Because I wrote them for myself and enjoy using them. A lot.
That sounds a bit insane and counter-intuitive, even to me. I’ve always considered it a mark of quality when open source developers actually use the code they’re slinging. How could I possibly keep in touch with the people who use my work if I can’t stand the taste of my own dog food?
What makes the code I love beautiful is the fact that it’s optimized to be
useful, with absolutely no sacrifices to make it easier to install or use or
keep up-to-date with the latest master branch. Which isn’t to say I leave out
documentation or only implement the one specific option I plan on using.
RabidRunner, for example, comes close to having more documentation than
code.
Basically, I look at the project from an entirely different perspective. Instead of catering to the busy developer looking to plug-and-play the bit of code I need to get the job done, I think in terms of what I would like to inherit if I were to find myself maintaining an established product.
I know I wouldn’t want to see a collection of vaguely-connected widgets, all wrapped up with their own configurations and data access procedures. Nor would I want to see a bunch of classes stacked on top of each other, each inheriting from a parent class just to add a bit of extra functionality.
I’d want to see a collection of single classes, each designed to do the job they were meant to do. And if I wanted to add functionality to the program, I’d do it in the simplest, most efficient way possible. Which means I wouldn’t implement a brand new class stacked on top of an abstract interface layer. I’d just add a function to the main class file.
If I wanted to make it easy to decouple two parts of the program, I wouldn’t jump through a ton of hoops to avoid one or two function calls from one module to the other. I’d just document which lines would need to be edited in the event that the application logic were to change and move on to more important things.3
At the end of the day, the code will be much, much cleaner than something based on a third-party library, but I’m not sure the benefits outweigh the added headaches.
Once you download my stuff and put your fingerprints all over my code, you’re not really a passive user of something I made and maintain for you. You’re a core developer of your own private fork.
And that’s a big damn responsibility when all you want is a unit testing framework.