3 ms·
As far as JSON, this is the part that's telling to me: "without using a lib/wrapper that hides the underlying implementation." It sounds like he's arguing about
by ori_b 13y ago
As far as JSON, this is the part that's telling to me: "without using a lib/wrapper that hides the underlying implementation." It sounds like he's arguing about generating it directly and parsing it by hand, although without context, I can't say for sure. If that's the case, I'd say the old fart is right on this one.
As far as facts, if you know a lot of facts, you can reason about how changing one fact (eg, "we write this value to this SQL table here, and we are going to stop doing it") allows you to reason about how other facts are affected ("Modules X and Y expect that data to be there").
- rob05c 13y ago> As far as JSON I wasn't clear on that example. If he's talking about CSV, there's nothing wrong with that (though I wouldn't call JSON "bad"). If he's talking about delimiting text with the bell character, yeah, that's ghastly. > without context I feel like most of the examples don't have enough context to make a fair judgement. If it's just a small amount in one place, simple formats like CSV and JSON can easily be parsed, and especially generated, manually. If they're used all over the codebase, manual parsing would create a huge amount of duplicated code. There just isn't enough context.
- icebraining 13y agoI disagree with him on the first; character-delimited strings are a pain. If you're going to hand parse, you're better off with a <length>:<bytes> encoding like Bencode uses. You don't have to escape the string, you can copy a whole block instead of scanning character by character and it plays well with UTF-8.