4 ms·

Both of those are fine, but they add additional complexities (even if small) where there is very little, if any, complexity added with using these two character

• Ukv 2y ago
  For machine-readable formats, I'd argue length-before-text is simpler to parse than splitting by separators - even before having to add extra application logic to handle this method being fallible (e.g: if you want to use it to store filenames, you now need a check and pop-up about some OS-valid filenames not being supported).
  • chrishill89 2y ago
    > For machine-readable formats, I'd argue length-before-text is simpler to parse than splitting by separators Yes. > even before having to add extra application logic to handle this method being fallible (e.g: if you want to use it to store filenames, you now need a check and pop-up about some OS-valid filenames not being supported). I don't see why you'd need that. CSV does not have anything like that. That's a higher-level concern. This ascii-delimited format (like CSV) is supposed to be a stupid row/column format. And also simpler to implement than CSV.
    • Ukv 2y ago
      > CSV does not have anything like that. If you're using a fallible CSV dialect, your application does need to handle that case in some way (or in some cases it may be fine just to let it crash). Something like length-before-text is convenient because you don't have to worry about that case.