Sunday, February 22, 2009

Self documenting code

I have been struggling all day with an odd Flash template for a website. The website owner wants to change the text (not a bad idea, since right now it is just variations on good old "Lorem Ipsum"), and that's what I am trying to do: write new text and then make the site display it where it belongs.

Except this is a funky template. There are almost no comments in the code, or in the XML file I am trying to work with. The functions I have been trying to figure out do not seem to accept variables in the standard way.

I know part of the problem is that I sometimes don't see the obvious. But a LOT of the problem is that the klutz who wrote the template couldn't be bothered to provide any instructions for it. Not any.

I remember interviewing a candidate for a job one time, and I asked what his opinion was on documenting his code, and he said, "I like to think that my code documents itself." Well. I'd like to think that, too; and it would be nice if my code gave me a back massage from time to time. But it generally doesn't do either: it just lies there waiting for you to grok the secrets of its functioning. And if you are not the author (and even if you ARE the author, six months later), it may never reveal its secrets.

How hard would it be to put together a little instruction that says, "Here's the three things you probably want to do with the text. Oh, and before you do them, make a backup copy of everything,"?

Too hard, I guess, for this guy. So he is off sipping his mint julep purchased with the avails of the sale of his crap template, and here I am a day older and not much further ahead.

No comments: