« What I've been up to (and why I've been glum) | Main | Mood swingy »

Debugging principle of the day

| 1 Comment

Say your code is suddenly wonky, but the only change you've made recently didn't have anything to do with the part that's being wonky.

Now say you try to fix the wonky bit, but your fix just doesn't seem to be taking.

When this happens to me, the usual cause is that the copy of the file where I'm making the fix is the wrong copy; I'm accidentally working in a backup file, or in a different directory, or on the live server instead of a staging server, or I just typed the wrong filename, or whatever.

But today, when my blog's front-page formatting went all weird (in a way unrelated to the tiny CSS change that I made yesterday), I kept making changes to the CSS file to fix the problem, and I kept double-checking, and the CSS file that I was editing was definitely the one that was getting picked up.

I pounded my head against this problem for probably an hour, getting more and more frustrated. (The one bright spot in all this was Chrome's Inspect Element command and the associated dev tools, which are very useful.) The right file was getting picked up, but no matter what I did to try to fix the problem, my fix was not getting picked up.

But then finally I tried changing something else in the same file, and that also didn't get picked up. And then I re-made the original fix, but near the beginning of the file instead of near the end, and that did get picked up.

And a lightbulb went off in my head, and I looked again at the change I made yesterday, which was in the middle of the file. I thought maybe I had accidentally left a comment open, thereby commenting out the rest of the file.

But it was even more basic than that. At the end of a chunk of CSS, you're supposed to use a closing curly brace } to indicate that your block is done. But I had mistyped the closing brace as an opening brace, with the result that the entire rest of the file wasn't getting read.

So here's my debugging principle of the day:

If something is misbehaving in an area unrelated to the change you made, take a look at physical proximity and other related factors. Because computers read files linearly, and certain kinds of mistakes cause problems for everything that comes after them in the file, whether related or not.

Corollary: When something is inexplicably wonky with your code, look to see what else is also wrong. If I had opened up one of my blog entries instead of stopping with the front page, I would've seen a whole lot of other CSS that had gone awry, and I might have figured out the cause sooner and spent less time focusing on the one specific symptom that I initially noticed.

I was familiar with this class of problem (especially wrt comments left open), but hadn't thought to apply that knowledge in this particular instance. I think that's partly because CSS does so frequently go awry in near-inexplicable ways, but partly also because I don't habitually jump to this issue as one of the first things to check for when there's wonkiness. (Also, at the moment I noticed the problem I was having unrelated intermittent Internet outages, which made everything harder to figure out.) By writing this up, I'm hoping to remind myself to add it to the first-things-to-check list.

1 Comment

A revision control system, especially one that can show diffs in a format you like, can really help with the "what the heck changed here" thing. I use them in all kinds of situations, from log files to code to text descriptions of things; there are *lots* of situations where I have a file and I want to be able to tell easily what I changed when.


Post a comment