InfLight -- an overview of Inform debugging

Roger Firth's IF pages
InfLight -- Inform debugging
InfLight -- Inform debugging

To end with, here are a few nuggets of advice on how to solve (or better, avoid) problems. In no particular order...

Without becoming paranoid, program defensively. Assume things may go wrong, probably on account of your mistakes and lapses. So, test for sensible replies, check a property is supplied before using it, always have a default clause in your switch statements...
Evolve a programming style that you're comfortable with -- naming, layout, indentation, etc -- and then stick with it. You need to be able to interpret your own code fluidly: Write Once, Read Many applies.
So do it; read the damn stuff. Work through your own logic, sceptically, trying to convince yourself that you've covered all the angles.
Indentation's a wonderful device, but it means zilch to the compiler. Use braces to enforce your statement grouping, and be wary of single-statement blocks (especially when adding to existing code). Similarly, take care to match else statements to the appropriate if. For example, you may have written the program on the left, but the compiler sees the logic on the right:
if (conditionA) if (conditionB) statement1; else statement2; statement3;
if (conditionA) if (conditionB) statement1; else statement2; statement3;
Remember that, although they're all numbers, the object cloak, the dictionary word 'cloak' and the string "cloak" are quite distinct. Check carefully what syntax is required, and don't try comparing apples with oranges.
Inform often uses routine return values of true or false to control what happens next. Are you concentrating? you'll get a return value of true from: print_ret..., "string", rtrue, return, return non_zero_value, and ] at the end of a standalone routine. You'll get a return value of false from: rfalse, return zero_value, and ] at the end of an embedded (property) routine.
Proceed in small steps -- write something, test it, write a bit more, test a bit more. This is true in spades if you're changing some existing code whose precise details are no longer fresh in your mind. It's a common and embarrassing trap to assume things all went wrong with your latest change; it could just as easily have been that trivial one-liner half an hour ago...
Be very grateful for Strict checking in the compiler, and leave it on throughout the development time. Then, when you turn it off prior to releasing your game, test everything again. Different code is generated, and you shouldn't assume the compiler is totally glitch-free.
Inform's good, but it ain't perfect. Before you get desperate, check the Inform patch site, just in case you're victim of a Well Known Problem.
The newsgroup rec.arts.int-fiction is populated by kindly helpful souls who like nothing better than to crack a clearly-defined and well-bounded problem. So, if you plan to ask for help there, be sure to give full details; a tiny cut-down example which demonstrates your difficulty is especially helpful.
But, before you post your message, pause awhile. It's amazing how many folks seem to solve their own problem within an hour or so of posting to the newsgroup. Compose your message -- it always helps to clarify your thoughts -- then hang onto it briefly before you send. After all, there's only so much goodwill to go round; don't cry "wolf" too often.

And that's all we've got time for...