Refactoring is a concept that is often used in the context of programming. In fact, it’s one of the cornerstones of Test-Driven Development (TDD) in Ruby on Rails. Oddly, I rarely see refactoring discussed in the context of writing CSS and XHTML. Whether you write Ruby, PHP, Perl or CSS and HTML, refactoring your code should be a part of your coding workflow.
So what is refactoring? It’s basically cleaning up your code, making it more efficient and easier to maintain. When writing prose, you bang out a first draft to get your ideas down on 
paper. It’s a bunch of crap often. Then you revisit your mess and make it beautiful and worthy of submitting to your local town paper.
Coding is no different. When writing XHTML and CSS I am often trying out things, adding extra divs and spans, and creating a mess of CSS and XHTML. It’s called the process. It’s messy. When I finally get to the look I wanted to achieve, I take a quick break and bask in the glory of having everything aligning and looking the way I had envisioned it to look. But I am not done yet. Far from it. I must refactor my code.
Refactoring code removes duplication, aids in readability and maintenance of the code in the future. The goal here is to make things simpler, while continuing to achieve the layout I have designed. If you refactor and suddenly something doesn’t look right, that is not refactoring, that is breaking something. You want to refactor in small steps and test your code in the browser to ensure things are still working as intended. You should be using some form of source control management (SCM) like Git and regularly checking your code changes in. This way if you botch something, you can always pull a working version out of your SCM.
Now you might be thinking to yourself, I write semantic markup, isn’t that refactoring? No, that’s called doing your job as a standards aware designer. You should always strive to create meaningful markup. That’s the name of the game. Refactoring is revisiting your code and identifying areas where your code can be improved, streamlined and made simpler. In six months or a year, when you revisit this code you’ll spend less time trying to remember how this code works because you took the time to make it simpler and easier to maintain.
Refactoring is a huge topic and I plan on addressing it using several examples in a series of posts on the topic. We are going to take some baby steps here. For now I will leave you with a simple refactoring of CSS.
I ended up writing this CSS code in a site I was working on today:
Do you notice something in this code? There is a huge amount of duplication here. The height and the padding-top attributes are the same for each of these classes. This duplication violates the DRY principle: Don’t Repeat Yourself. Duplication is a very bad thing. If we want to change the height, we have to change it in four places. This is not ideal. A better approach would be to refactor this CSS and remove the duplication and place it into a group of parent classes:
So here I have refactored out the duplication and placed it in a group of parent classes. Now if I want to change the height of padding of these elements, I just need to deal with making the change in one place. The readability has been improved along with the maintainability. And I have saved a a few lines of CSS. While not a huge amount in the small example, the LOC saving in a large CSS file can measure in the kilobytes!
Thats it for now. If there is one takeaway in this lesson, it is look for and eliminate duplication whenever possible. Stay tuned for more examples of CSS & XHTML refactoring.
