When to Refactor

Thursday, May 29th, 2008

Here’s part 3 of the ongoing serialization of Refactoring HTML, also available from Amazon and Safari.

When should you refactor? When do you say the time has come to put new features on hold while you clean up and get a handle on your legacy code? There are several possible answers to this question, and they are not mutually exclusive.

The first time to refactor is before any redesign. If your site is undergoing a major redevelopment, the first thing you need to do is get its content under control. The first benefit to refactoring at this point is simply that you will create a much more stable base on which to implement the new design. A well-formed, well-organized page is much easier to reformat.
(more…)

Why Refactor HTML?

Wednesday, May 28th, 2008

Here’s part 2 of the ongoing serialization of Refactoring HTML, also available from Amazon and Safari.

How do you know when it’s time to refactor? What are the smells of bad code that should set your nose to twitching? There are quite a few symptoms, but these are some of the smelliest.

Smell: Illegible Code

The most obvious symptom is that you do a View Source on the page and it might as well be written in Greek (unless, of course, you’re working in Greece). Most coders know ugly code when we see it. Ugly code looks ugly. Which would you rather see, Listing 1.1 or Listing 1.2? I don’t think I have to tell you which is uglier, and which is going to be easier to maintain and update.

(more…)

Refactoring HTML: Chapter 1

Tuesday, May 27th, 2008

Over the next week or two I’m going to serialize the first two chapters Refactoring HTML here. Of course, if you don’t want to wait you can always buy it from Amazon or read it online on Safari. And with that brief commercial announcement out of the way, let us begin:

Refactoring. What is it? Why do it?

In brief, refactoring is the gradual improvement of a code base by making small changes that don’t modify a program’s behavior, usually with the help of some kind of automated tool. The goal of refactoring is to remove the accumulated cruft of years of legacy code and produce cleaner code that is easier to maintain, easier to debug, and easier to add new features to.

Technically, refactoring never actually fixes a bug or adds a feature. However, in practice, when refactoring I almost always uncover bugs that need to be fixed and spot opportunities for new features. Often, refactoring changes difficult problems into tractable and even easy ones. Reorganizing code is the first step in improving it.

If you have the sort of personality that makes you begin a new semester, project, or job by thoroughly cleaning up your workspace, desk, or office, you’ll get this immediately. Refactoring helps you keep the old from getting in the way of the new. It doesn’t let you start from a blank page. Instead, it leaves you with a clean, organized workspace where you can find everything you need, and from which you can move forward.

(more…)

Yes, the Feeds are Broken

Monday, January 14th, 2008

This weekend I finally noticed that the Atom and RSS feeds from this site are 404. I’m not sure why exactly yet. It may have to do with the upgrade to WordPress 2.3.2 or it my be a result of the switch to shared hosting on pair.com. I’m out of town at the moment but I hope to fix it tomorrow.

elharo.com also seems to be completely down. I’m not sure why. I may just need to reboot the server when I get home. I haven’t yet transitioned that site to pair.com. Instead it’s still sitting on the Mac Mini in my office.

Update: I think I have the feed problem figured out now. Holler if anything still looks broken. It seems that the .htaccess file did not get uploaded when I uploaded the rest of the files from the old site. Hidden files are evil.
(more…)

Turn On Autocomplete

Tuesday, September 25th, 2007

The following is a possible new chapter to be added to Refactoring HTML in the accessibility section. I’m throwing this in fairly late in the editing process, so I’d appreciate any thoughts, comments, or criticisms you might have about this. In particular, I’d appreciate any cases you can think of where autocomplete is not appropriate.

For what it’s worth, I’ve pretty well convinced myself that usernames and passwords are not such a case. That is, autocompleting usernames and passwords definitely increases accessibility and usually increases security. I don’t intend to explain why it improves security in this chapter, but if anyone wants to disagree with that, I’ll explain why in the comments.

Remove autocomplete=”off” attributes where appropriate.

<form action="/login" method="post" autocomplete="off">

<p><label>E-Mail Address:
<input type="text" name="e1" autocomplete="off"/>
</label></p>

<p><label>Password:
<input type="password" name="p1"  />
</label></p>

<input type="submit" title="Login" autocomplete="off"/>

</form>

<form action="/login" method="post" autocomplete="off">

<p><label>E-Mail Address:
<input type="text" name="e1" />
</label></p>

<p><label>Password:
<input type="password" name="p1"  />
</label></p>

<input type="submit" title="Register" />

</form>

(more…)