Think back to the first time you wrote some code. It might have been:

<h1>King Crimson Rules!</h1>

Or maybe:

[BASIC]

10 PRINT "I repeat myself when I am in stress"

20 GOTO 10

[/BASIC]

No matter what it was, chances are the first thing you saw on your screen was:

SYNTAX ERROR Near line XX.

Can't you even type?

Why are you so stupid?

Maybe some of you have perfect queries dripping from your fingers, and well-formed functions hopping across your keyboards. Perhaps you dine on multi-dimensional arrays and wash them down with precisely nested ifs—but I know I sure don't. If you're like me, you've probably seen more error screens than 200s.

Whether writing server-side, client-side, or regular-old-markup, you need to develop some debug muscles. Errors are an incurable side effect of human programming, and when they pop on your screen, you can probably hear your bank account draining. Become an adept debugger and you'll write cleaner apps, in shorter time.

Bigger Debuggers in 12 Easy Steps

Considering how much time we all spend debugging, it is ironic how rare a topic it is in books and conversation. So how does one become a better debugger? Hopefully, the twelve guidelines I've compiled here will help you squash bugs faster, smarter, and with more authority.

1. Organize your code.

Let's face it, building websites isn't rocket science. If you've been at it for 6 months, you've probably developed some sort of methodology. All sites share common elements, pay attention to what they are and re-use code as much as possible. Organize your code and includes so you know where everything is.

The W3C is pushing standards that separate content from structure; you'll find adopting this philosophy helps when debugging as well. Some general guidelines:

2. Isolate and identify the problem.

This is the key to all debugging, and a close cousin of code organization. The problem code block must be identified, and identified quickly. If you're debugging-while-developing (DWD), you know the first place to look is the code you were just working on. If you're debugging-while-updating, or wading through someone else's work, isolation becomes more difficult.

3. Validate it!

Make the validator your home page. Writing valid HTML of some flavor is an excellent first step in error prevention. If you're new to validation, start with 4.01 Transitional. There are also many standalone tools available, the W3C maintains a list here.

4. View the source, Luke.

When you're working server-side, many times you can find problems faster by viewing what came out, rather than looking at what went in. Check the output, test variables using HTML comment blocks, or use a simple JavaScript alert to dump server-side variables. If you're dealing with a variable that changes throughout the page, output it several times.

<script language="JavaScript" type="text/JavaScript">

alert('$some_variable');

</script>

5. Be the layout master, not the master layouter.

When dealing with a layout problem, first determine if it is an HTML or CSS problem.

6. Man-handle forms.

Everyone hates forms. If you don't, you haven't done enough multi-page checkouts yet. Bulletin boards everywhere are crawling with people having form trouble, and it's almost always related to bad-HTML or a misnamed field.

7. Write clean queries.

An extremely typical data-driven website scenario: You write a query in whatever, and then try to output the results. Sounds fine, but how often do you actually test the query output in its entirety? A good cabinetmaker measures twice, and cuts once. Most programmers measure a little, and hack it with an axe until it fits.

8. Organize your variables.

Keep your local variables in a structure or array. If you store all your local variables in one object, it is much easier to dump their values onto the screen as a whole, which is an invaluable tool when debugging.

9. Proceed slowly, preview often.

When you first started coding, you probably previewed every <H1>, and scrutinized every <img .../>. Typically, the more experienced programmers become the more code they'll write before previewing.

10. Mirror your test and production setups.

If you've ever uploaded files to the server with a local path unchanged, take off your left shoe and eat it. The feeling is right up there with sitting in the Principal's office, or locking your keys in your car.

11. Work like a debugger.

Make your work environment work for you. I like to hog as many machines at once as possible, coding on one and previewing on the others.

12. Don't waste time, take a break, ask for help!

Don't spend more than 5 minutes trying to fix something (unless you've really done it this time).

Flex Those Debuggers

Hopefully, this article has gotten you to think about how you debug, which may in turn get you thinking about how you construct your web applications. As programmers, we feed our bottomless curiosities with small victories, and fuel our fires with the burning cinders of lift-off catastrophes. So get out there, write a whole heap of errors, and be proud when you bomb the whole server.