3 ms·
If Excel compatibility is the goal, one should use libraries that read and produce Excel files. CSV is bullshit, it's not good for anything except scenarios wh
by mantrax5 12y ago
If Excel compatibility is the goal, one should use libraries that read and produce Excel files.
CSV is bullshit, it's not good for anything except scenarios where you control both the export process, and the parser (so you know what delimiter is used and so on).
- minimaxir 12y agoThe same could be said about exporting to JSON. (the JSON code on some of the big APIs does not parse intelligently and I have to spend a lot of time fixing it.)
- deleted 12y ago[deleted]
- mrweasel 12y agoCSV files are MUCH easier to search and inspect using tools like grep and less. It's the accounting people that want's Excel, but as a developer CSV is easier and more flexible. We process csv files containing payment information, export csv as product feeds for perhaps 10 different partners. It works, it's faster than XML or JSON and is easy for non-technical people to inspect using tools like Excel. Most cvs data exports are not something that's made up on the fly every day, it batch jobs that create the same type of CSV file each and every time. CSV is alright. XML is bullshit.
- Roboprog 12y agoCSV is much simpler when the records are all of one type. It gets debatable which (XML vs CSV) is simpler when you get multiple record types dumping a hierarchical data structure. Obviously, you can make CSV files work for alternating record types, in the same way that the old mainframe files used to work with multiple record types in a file, with a type descriminator field in a know place, usually field 1, of each record. But it starts to get cluttered.