Here's a quote from a great programming book I once read, also paraphrased (I think it came from either Debugging the Development Process
or Writing Solid Code
):Whenever you find a bug in your code, you should ask yourself two questions: (1) How could I have easily (or automatically) detected this bug? (2) How could I have prevented this bug from happening in the first place?
In my opinion, anything that causes you to spend a lot time debugging is an opportunity to learn, even if it turns out to be just a typo. You have to ask yourself, "Why did a simple typo cause me to lose so much time? How can I change things so that typos don't cost me so much in the future?"
I can think of a bunch of possible lessons in your situation (of course, none of these lessons might apply in your particular case):
- XPath is full of traps and it's easy for an innocent-looking typo to spoil a query.
- People are so used to reading "\\" as "\" (because of the use of backslashes in escape sequences) that making "//" have a different meaning from "/" was a poor design choice on the part of the XPath folks*
- I need to wrap my XPath expressions in a helper function that sanity-checks them.
- I need to wrap my XPath queries in a helper function that sanity-checks their results.
- Rather than code most of my XPath expressions by hand I should have a function that creates them according to a certain template, so that I'm less likely to make mistakes.*In fact, I would argue that the very existence of XPath is a classic case of the primitive obsession code smell.