Sign in to follow this  
  • entries
    191
  • comments
    861
  • views
    116832

Beware the .QIF

Sign in to follow this  
Mithrandir

122 views

I'm convinced that people who make datafile formats are on crack. There's no other explanation.


I recently had the brainfart idea that making a QIF importer for TFM was a good idea. For those of you not in the know, a .QIF is a "Quicken Interchange Format" file. It's simply a list of transactions.

Or is it?

Hah, it isn't. You can also store categories, accounts, arbitrary data, etc, in it. And the best part is that none of this is really standard. The format has no formal layout; you can pretty much stash things into the file any way you please. It gets better, because there is no standard date format or currency denotation.

When I examined my first .QIF file, I thought "well this should be easy!". Dates, for example, were formatted MM/DD/YY. Easy enough.

So I went into Quicken to export some data, just to see if it does anything different than my bank. It spit out a file that looks almost nothing like the one my bank gave me.

The most WTF thing ever: dates were formatted like this:

:mM 'dD /yY

For example, today would look like:

":3 ' 9 / 6"

What. The. Hell?!


Since when is that a valid date format... anywhere?!


Not wanting to give up after hopelessly comming to the conclusion that a homebrewed solution is going to be significantly more difficult than I originally anticipated, I decided to take a look at GNUCash's implementation of a QIF importer.

Hahahaha. Hoh boy. Not only does it mix C++ and Scheme and Regex code altogether in one giant mess, they use huge undocumented macros all over the place, and have even typedeffed their types into oblivion.

gboolean? Come on! I mean, yeah, it's a good idea to typedef types in case you're going to different platforms where the bitsizes are different (though to be honest, I've never actually run into this; and it seems like a purely academic exercise in reality)... but typedeffing a boolean? What, are you afraid that someday someone's going to port your program to a system that supports Filenotfoundian logic?



So anyway, I've given up on QIF's. I may come back to it someday if I ever find a pressing need to be able to import them, but for now... it's just too ridiculous, and I'd rather not fan the flames by supporting an idiotic file format any further.
Sign in to follow this  


3 Comments


Recommended Comments

It usually goes something like this:

app.v1 comes out and it has a nice basic very simple file format that is completely non-extensable.

app.v1.5 fixes some bugs caused by the v1 format being ambiguous in a few places. Unfortunately fixing the bugs and preserving backward compatibility with v1 requires being a little "creative".

app.v2 comes out with some new features. The v1.5 format needs to be extended a bit but it's not to bad.

app.v2.5 comes out and adds support for internationization. The developers realize they're basically screwed when somebody tries to mix English/Chinese/Arabic/Urdu in a single document. They hack something up so it mostly works but the file format spec (assuming there ever was one) is starting to look a bit ratty with all the special-cases and compatiblity hacks.

app.v3 comes out. This is the big one. It's got 10,000 new features and a completely re-designed file format that nevertheless tries to be compatible with the old format because a significant portion of thier customers demand the ability to be able to exchange documents with un-upgraded v2 and v2.5 installations.

v3 is a runaway hit. Everybody and thier brother reverse-engineers the file format and creates buggy importer/exporters that don't handle all the special cases because the third-parties have never seen that situation (they don't have Urdu language support installed in thier OS), because they can't believe the original developer would do something as apparantly stupid as they did, or because they're just bad developers. Two or three of these become big with the customer base despite the original developer's misgivings. The original team cashes in and quits. Any original documention is lost. Management hires a bunch of red-cheeked college kids who are willing to work 16 hour days.

app.v4 comes out. The new dev team only barely knows what it is doing. 75% of the customers are using buggy importer/exporters in third-party apps in critical line-of-business scenarios. The developer is forced to support not only thier own stupid stuff (which they don't really understand themselves) and all the buggy third-party stuff (otherwise thier customers would scream bloody murder or even worse not shell out the bucks for the upgrade), but now they need to extend it *again* in ways that weren't considered during the big re-design of v3.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now