I worked with file formats for a while during my career. I also saw a lot of them, produced by others. It is shocking how many bad decisions people do when designing file formats, in particular when it comes to a fundamental point
Whatever you write on the customers’ disk, is going to stay, and you will have to support, forever.
And with this consideration in mind, it’s incredible how poor thinking is done on file formats, both for input and output. Here are what I believe to be typical design mistakes of a file format.
- Putting the creation time and date. This metainformation may be somehow useful, but it's already supported by the filesystem. Unless you need to keep history information, it makes no sense. In addition, it makes the task of testing the output for correctness much harder, because in some cases, a quick and dirty md5 does the job. With a "creation date" inside the file, the md5 changes at every run, unless you can override it. - Putting a "creator" information. in some circumstances this is rather irrelevant. Say you have a program A creating the file. The file now contains "A" as creator. Now you open the file with program B, modify the file considerably, and save it. Who is now the creator ? well, technically A, but this information is largely irrelevant. A didn't provide all the information stored into the file. - No version. This is so obvious that when I see no version information into a file format I start to wonder if the one who deployed the file actually knew how to code. - Version as a floating point number. Ok, you decide your file version is "1.1", but that does not mean it must be a floating point number. You are very likely to extract that value from the file and then check it for equality in order to do things. Comparing floats for equality is a no-no, and in any case it does not make sense. A floating point number is used to perform math operations. A version number is an identification token. Do you really plan to do the square root of your file version number anytime soon ? - Reinventing the wheel, squared. This is incredible. One of the big problems of data is how to lay them out on the disk. A file format will most likely contain different kind of data, and may need to be portable across different platforms. You may also need some kind of check in order to see if the file is somehow corrupted at the basic layer of storage, before opening it. Some output files today are zip files, masked as something else. ODP is a zip file, and so is JAR. If you store computational data, HDF and NetCDF are good choices. This is very convenient, because it solves you the problem of disk representation, leaving you only the problem of semantic representation of your data. - Lack of uniformity, lack of official specification. - Lack of an IO layer.