[cjfd]

It is generally good to depend on well-tested, large and reliable libraries. I have done the code-it-yourself thing to smaller libraries, though. The quality of the maintenance work done on smaller libraries is by no means guaranteed. They can acquire bugs at any point in time and when they do it may be best to just replace them by home written replacements.

[orclev]

A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you. In a similar vein, a well known standard format (or encoding) will always be a better choice than some ad-hoc format you create yourself because not only will that standard have encountered and dealt with problems you haven't even considered, but there are also likely to be a plethora of libraries, frameworks, and tools that support that format, where as if you create something yourself you end up needing to create anything you need.

Your time is generally better spent working on solving your core problem rather than the dozens of ancillary problems that end up needing to be solved along the way (particularly where a whole bunch of other people have spent a whole bunch of time already solving those problems).

[Ma8ee]

> A large complicated well maintained and widely used library is infinitely preferable to a large complicated library you need to maintain yourself and used only by you.

Yes, but a large complicated well maintained and widely used library is not necessarily preferable to a small not so complicated library that does exactly what you need and nothing else. And that goes for formats too.

Recently I was involved in a project where order numbers had to be sent from one system to another. Some colleagues insisted that we baked them into a large xml document and then used libraries to both create the documents as well as parse them. In this case the economic thing to do was to write them each separated by EOL. Even the code we would have written ourselves would have been larger if we’d used the XML solution, not to talk about everything needed to include in builds and deploys.

[orclev]

There's an important difference between using something because it's popular, and using something because it's a standard designed for your problem. For something simple like just sending some numbers across the wire XML is massive overkill (as an aside, there's actually very little XML is a good solution to). CSV, TSV, JSON arrays, one of dozens of serialization formats, or even just a simple EOL separated value like you proposed are all both standardized and very simple solutions to the problem. On the other hand, had they proposed inventing some new binary serialization protocol and using that to transmit the numbers, that would be even worse than using XML.

You should always pick the simplest solution to the problem that meets all your requirements, but when considering solutions you should favor standards compliant solutions. A common example is date formats. Lots of places roll their own date format string when sending dates, but using ISO-8601 will save you (and your clients) so many headaches in the long run.

Honestly for your example, not knowing all the details I can't say for sure if a EOL separated value is a good solution, but based on just the description I probably would have gone with a CSV, or possibly a JSON array. I definitely would not have used XML (dear god, why would anyone pick XML in this day and age?), although if they were concerned about needing to add more data down the line I could maybe see an argument for something a bit more involved than a CSV.