One of the best feelings that one gets from being a developer is the sense of elation that comes with finishing a product. You make the last change or addition to the code and that particular key stroke designates the product as done (at least for that version). Once complete, the code sits there unchanged, often times for very long periods of time. If it works, why change it? No need to, right? No, wrong.
Nearly every time I work on a plugin, I get the sense that tells me it is some of the best code I’ve written. It’s better than the code I wrote yesterday, and it’s better than the code I wrote a year ago.
If you have that same sense about your own code, then that means that ALL code you have ever written can be improved. This is part of the reason that I would strongly encourage you to make a habit of refactoring your code over time, at least for products that are publicly available.
I spent about five hours today going line by line through my Restrict Content Pro plugin. The plugin has over 110 files and a many, many thousands of lines of code. It’s a really large plugin, and I went line by line through every single file making improvements. The primary improvement I was working on was adhering more closely to the WordPress coding standards. This is something I feel very strongly about, but, unfortunately, did not use to follow very closely.
Over the course of 88 commits to the plugin’s Github repository, I added 1,698 lines of code and removed 1,759 lines. Overall I shrunk the plugin by nearly 100 lines.
A lot of my changes were simply improved white space and code formatting, but through the process of going line by line, I also found a significant number of security vulnerabilities and poorly sanitized data. Many of these issues were present because when I first wrote the plugin, I didn’t know very much about data sanitization or SQL injection vulnerabilities.
Before I started on this code refactoring escapade, I was not aware of many of the issues I found, and I was only able to fix them because I chose to go line by line through the entire plugin.
I’m constantly amazed at how quickly our skills as developers progress. Yesterday I opened a plugin I wrote a few months ago and was pretty disappointed with some of the code I found in it. That plugin wasn’t even three months old.
By forcing ourselves to sit down and go line by line through projects we’ve written in the past, not only do we dramatically improve old code, but we also gain a huge sense of accomplishment by seeing first hand just how far we have progressed in our development skills.
Part of me was really disappointed in what I found today, but another part was highly elated because I realized just how much I have learned in the last year.
We make ourselves better by not just learning new techniques, but also by learning what bad techniques are, and I assure you, one of the best ways to remind yourself what bad techniques are is to look at your own old code.
Would love to see the actual code before and after. Especially highlighting the vulnerabilities, so we can learn best practices for good PHP coding.
Here’s a couple of examples. Previously, whenever a subscription level was updated, the code that performed the SQL query looked something like this:
This query is susceptible to SQL injections, and to improve it, I simply did this:
The $wpdb->prepare() member function is the one designed to protect against injections.
Another example would be the input fields used throughout the plugin for settings and such. Most of the data displayed in these forms was simply raw data, which means that if a user entered something (such as improper HTML) it could cause issues, including breaking of layout. To fix it, esc_attr() and other validation functions were used:
Writing code is funny thing, because I can definitely identify with this:
And that’s something that happens with every language and/or library and/or framework, you know? You get comfortable using it for a while and then you get into this groove of writing really good code in it.
Then you look at the code a few months later and … it’s as great as you thought. I think that’s the nature of programming.
But following your advice and refactoring it overtime is smart – it’s like investing in your code: Small deposits over time end up leading to a much higher quality product.
I’m always surprised at how quickly my code quality declines. overtime. I’d say it’s a great testament to how quickly we learn.
I see this all the time, working with students. There is a constant struggle to refactor and refactor because many of them improve so quickly. And it’s not a bad thing, it’s good really, and it becomes a matter of pride for them to be able to go back and refactor something they wrote just a short time before.
I view it as a great measure of improvement when you look at something you wrote 3 months or a year ago and go, “What was I thinking doing it that way?” or “Wow, this is really inefficient.”