3 ms·

That tip about assertions is great! It would tell you immediately when one of your assumptions is wrong... One tip I have, which might be obvious: Write docs a

That tip about assertions is great! It would tell you immediately when one of your assumptions is wrong... One tip I have, which might be obvious: Write docs as you work. While I was working on an app that reads MS Access file, I simultaneously worked on a guide that documented everything I found out: http://jabakobob.net/mdb/ http://jabakobob.net/mdb/ That guide will be useful when I need to fix a bug in the future, and I hope it will also be useful for other people.

MichaelCrawford 12y ago
Indeed. I didn't mention that, but that's something I do myself. Really the written documentation is far more important than any code. Consider someone who wanted to write a file filter in some other programming language. I use C or C++, they don't look a whole lot like Python or Haskell. Really the written document should be regarded as authoritative, and not any of the code. However, it's not clear how to go from a written specification to a working file filter. One way that would work well but that would be laborious, would be to give the doc to someone who had no prior knowledge of the format in question, so they could write their own filter. If I gave such a doc to you, then you and I could round-trip our files back and forth between my implementation and yours, then we could be quite confident that the document was correct. To this very day, OpenOffice will not round trip my resume between .odt and .doc. The are is subtle but I can see it every time I try.