Hacker News Reader

Comment by legostormtroopr | Hacker News Reader

There are a ton of problems here:

* From the documentation "No quotes needed for values ... Use dual quotes ... Use triple quotes"

* You haven't solved the problem of describing what the columns are. In fact, its worse because you are encouraging people to put units in the field

* Spaces matter! What if the data is literally " Word " vs "Word". This format makes them both the same.

* For some reason, the header row is removed. The only thing in a CSV that provides structure is gone. In the first "improved" example, I have no way of knowing what the columns meaning without them.

The only good improvement in this is the "#" convention as a comment. If we could get every CSV parser in future to agree (we already can't get them to agree now) to ignore lines that start with "#" then CSV's would be vastly improved.

View on HN

> Spaces matter! What if the data is literally " Word " vs "Word". This format makes them both the same.

If leading and/or trailing whitespace are significant, you can quote the value. Problem solved.

Having said that, almost always when you see data persisted with leading or trailing whitespace it should have been trimmed away before storage.

Edit to add: your main points are spot on, IMO, but:

Original: I'm not even sure I agree that 'comments' are good, particularly if they're going to be intentionally ignored by GUI s/s apps.

If you have meaningful information, put it in the furthest right-column, so it appears in spreadsheet editors on the right of the data.

If it's not meaningful to the person who will open the file, why include it?

Regarding quotes, they're optional (e.g. when you need a comma, leading whitespace, or newline). With arguments by position possible I guess colons have to be quoted too.

It's not clear to me that it's possible to convert this to a standard CSV; it can't guess the header and guessing whether a column contains units (consistent units?) is asking for trouble.

More pragmatically I can't share these with other people because they're almost like a csv, but incompatible.

It's great to try to make CSV more readable (I like the leading whitespace, but it'd be finicky to maintain with simple text editors), but not worth the technical risk of format confusion.

Hello, I'm the original author of CSV 1.1.

There are no problems :-). You're making up things / problems.

Nowhere says it that the header row is removed. You CANNOT auto-detect a header, you have to tell your parser (see the csvreader library as an example - https://github.com/csv11/csvreader - from my humble self.) if you have a header or not (it's optional).

If Spaces matter! but them in quotes. By default you don't need quotes (and, thus, discouraged).

> You haven't solved the problem of describing > what the columns are

That is solved / done by a schema with a (tabular) datapackage, see https://github.com/csv11/csvpack as a real-world example how that works in practice or use csvrecord, see https://github.com/csv11/csvrecord

> If Spaces matter! but them in quotes. By default you don't need quotes (and, thus, discouraged).

So, just like a regular CSV?

Reply on news.ycombinator.com