Nice spec



  • Working on a data conversion program to output data to a fixed length flat file.  The verbal instructions I got when handed the spec included "left justify and pad right with spaces any text fields and right justify and pad left with zeroes any number fields."  This is what the spec had for one item.

     

    <FONT face="Times New Roman" size=3>To                   From                           Description</FONT>

    <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /><o:p><FONT face="Times New Roman"> </FONT></o:p>

    <FONT face="Times New Roman"><snip></FONT>

    <o:p><FONT face="Times New Roman"> </FONT></o:p><FONT face="Times New Roman">12        -           45                                Item Number  (15 characters, right justified)<o:p></o:p></FONT>

     



  •  I am so confused.  I'm going to give you the benefit of the doubt and assume that your description is clear and the spec makes no sense.  Under those assumptions, I applaud your WTF for momentarily shutting down my brain.



  • Is the WTF that it's from 45 to 12 instead of the other way round, or is it that 45-12=33≠15?



  • both.  although the To-From swap is more of a typo than a WTF.



  • @derula said:

    Is the WTF that it's from 45 to 12 instead of the other way round, or is it that 45-12=33≠15?
     

    There's also the minor WTF of it being an item number but apparently a character field.  And of course there's the much bigger overarching WTF of fixed-width fields, which went out of style about 20 years ago.



  • @Aaron said:

    @derula said:

    Is the WTF that it's from 45 to 12 instead of the other way round, or is it that 45-12=33≠15?
     

    There's also the minor WTF of it being an item number but apparently a character field. 

    Not necessarily. Many so-called "item numbers" actually contain letters, dashes, or other things that could not be stored in a numerical data type. Consider, for instance, the International Standard Book Number, which can often contain an 'X' and whose dashes are in different places depending on where the book in question was published.

    @derula said:


    And of course there's the much bigger overarching WTF of fixed-width fields, which went out of style about 20 years ago.

     

    But I won't argue with you on this one.



  • @Someone You Know said:

    @Aaron said:

    There's also the minor WTF of it being an item number but apparently a character field. 

    Not necessarily. Many so-called "item numbers" actually contain letters, dashes, or other things that could not be stored in a numerical data type. Consider, for instance, the International Standard Book Number, which can often contain an 'X' and whose dashes are in different places depending on where the book in question was published.

     

    I know that; but it definitely adds confusion when the spec says that you need to treat number fields differently from text fields, and the name of the field contains the word "number" when it is actually a text field.  "Item code" would have conveyed the same concept but been far more clear.



  • @Aaron said:

    And of course there's the much bigger overarching WTF of fixed-width fields, which went out of style about 20 years ago.
    ISO 8583 is quite full of them, and is still being used today (just finished setting up a system with someone who uses a modified version of it). Not sure if it counts though since it's a binary string.



  • @Someone You Know said:

    @Aaron said:
    And of course there's the much bigger overarching WTF of fixed-width fields, which went out of style about 20 years ago.
    But I won't argue with you on this one.

    Fixed that quote fail for you. And yeah, fixed-width fields are strange, although so much easier to parse... Except when they suddenly decide they need longer fields ;)



  • Fail? Fail? Fail?

    Maybe you meant "error"?



  • @Aaron said:

    @derula said:

    Is the WTF that it's from 45 to 12 instead of the other way round, or is it that 45-12=33≠15?
     

    There's also the minor WTF of it being an item number but apparently a character field.  And of course there's the much bigger overarching WTF of fixed-width fields, which went out of style about 20 years ago.

    Unless you need to export data to a mainframe.

    Fixed width fields and storing numbers in character fields (COBOL, probably) are very mainframe-y, and very common in many old apps.



  • Fortunately, it isn't necessary to store your data in a silly format just to be able to export to that format.



  • Although there's a lot of WTFery I can't even pretend to defend here, the mismatch between the declared field size and the allotted field size is not always a WTF. There are a lot of reasons you can wind up with such things.

    For example, it may have been desired to have to total record size be an even divisor into the disk block size. This allows the system to cache, say 16KB blocks of file data and not have to deal with the case where a record spans a cache line.

    So you may have a field that's 15 characters wide (in the sense that the maximum content it is defined to carry is 15 characters) that has more than 15 characters allotted for it (because more space had to be filled anyway).

    I generally prefer to leave all the blank space at the end. But it makes it easier to enlarge a field without having to move around all the other fields if you distribute the blank space.

    That said, fixed-length fields in flat files are almost always WTFs.


Log in to reply