Most visitors to a web page will only see how it is displayed in their browser of choice. They don’t know (or care) how the code that generates that page appears. So why should we as developers care? Because we’ve been told it’s the right thing to do? Well, okay, I guess. If I’m going to spend the extra time required to write clean code, though; I’d like to know a good reason why. (In this post, I refer to clean code and optimized code interchangeably.)

Maybe I should start by asking what constitutes optimized code? I usually think of it as code that is executed quickly. It should use the least number of lines necessary to accomplish the task and be relatively easy to read and maintain. In practical terms optimizing your code usually involves removing any unnecessary fluff and organizing what’s left into an easily understandable format.

Benefits

Keeping your code clean and shiny usually results in smaller files. That translates to a smaller footprint on your hard drive. More importantly, it means less of your bandwidth is eaten up each time that file is called by a web surfer. It also means your pages will load faster, most notably for visitors who are using a slow connection.

Your code will also be much easier to read. I remember in my first few years as a developer, I didn’t give that much consideration. I was the only one who needed to look at the code, and I didn’t need it to be formatted any particular way to understand it. After a few years I learned what every developer eventually learns.

First, you’re never the only one who looks at your code. You may be the only one who looks at it for the first year after it’s written, but other people are going to need to read your code down the line. It could be your successor making changes, a potential client looking for examples of your work, a peer, but definitely somebody. Second, going back and reading code that I wrote a few years ago is like reading a foreign language. I’m constantly growing and developing new techniques for solving problems in code. (Who can honestly say that they’ve never once used nested tables for a page layout?) Digging through some of the code I wrote before I cared about keeping it clean can be jaw-droppingly time consuming. Going through my more recent and well-formatted code is much faster.

You should also feel a sense of urgency to optimize your existing code and begin writing new code with optimization in mind. I almost never start anything from scratch anymore. I almost always copy something similar that I’ve done in the past and begin changing it to fit the specific circumstance. I have the impression that’s how most developers work. The longer you wait to start writing clean code, the longer you’ll be copying and pasting the same problems into everything you do.

Scrubbing

1. Set Aside Time – One of the first objections to optimizing code is that it takes time. You may feel like you already need more hours in the day to get done the project work that you have in front of you. Just believe me when I say this is important. It’s worth making the time.
2. Use a Text Editor – WYSIWYG editors have a lot going for them. They allow you to manipulate the page in miraculous ways. The trade off is that you lose control of the code being created. Your HTML will be loaded down with unnecessary style markup. I believe it is an unfortunate truth that if you can’t work in a text editor, you can’t create clean code.
3. Prioritize – If you’ve got a really big site to optimize, don’t feel like you need to get it all done at once. Start with the files that get hit most often: the home page, included header files, the image with the company logo, stylesheets, et al. Which brings us to…
4. Use Stylesheets – If you aren’t using stylesheets, that should be your number one priority. Go directly to this tutorial. Do not pass Go. Do not collect $200.
5. Indent Consistently – Everyone has personal preferences about when to indent. Maybe you like to keep all of your <td> tags on the same vertical line as the <tr> tag that contains them. Maybe you like them all to be indented. It doesn’t really matter, but your code becomes much easier to read if you are consistent.
6. Search Your Comments – Do a search for all instance of the characters to begin a comment in your code. ( <!– and // and /* and anything else you use) If the comments make the code easier to understand, leave them there. It makes your file a little bigger, but the trade off is probably worth it. If the comment is a line of code that you were trying during development, but it isn’t ever going to be needed in the production version of the web site, then delete it. Depending on your development style, there may be a little or a lot of these.
7. Remove Orphan Files – Start by looking for any HTML files that you don’t link to or include anywhere on the site. They were probably used at one point, but are now just taking up space. The same can be done for images, stylesheets, and any other file on your web server. Note: Development files such as Photoshop files should be saved, just not on the web server.
8. Meaningful Variable Names * – As you go through your comments, look for instances where they are used to explain the purpose of a variable or function. Could you change the name of the variable or function to something that makes the comment unnecessary? The line of code name = “Johnson”; might require a comment explaining that the variable name is the default last name for any new record added to the family tree database. The line of code DefaultLastName = “Johnson”; is pretty clear without a comment. On top of that when the variable appears later in the code, you won’t need a second comment to explain it again.
9. Remove Orphan Functions * – If you have a function library, look for functions that are defined but never called anywhere in your code. Be very certain that they aren’t used anywhere before deleting them. (A good strategy is to comment them out for a few weeks or even months. If nothing breaks, then you can probably safely remove them.)
10. Loop Intelligently * – Using loops in your dynamic pages can make your code vastly easier to read if done correctly, but all of the tips mentioned above are even more critical in a loop. Avoid putting comments inside loops unless they are important. You only read the comment once when you look at the code, but your processor reads it each iteration of the loop.

*only applicable to dynamic pages

As we look at comments, indenting, and variable names; it becomes clear that optimizing your code involves trade offs. Code that is easy to read is going to involve a lot of extra characters that increase the file size. Page load times suffer accordingly. Your objective should be a balance of performance and maintainability.

By no means is this list comprehensive. These are just some of the things that I’ve put into practice in my own code. If you’ve got other good tips, sound off in the comments.

filed under: Web Development