Glorious. I remember some hilarious nonsense in an API where the devs I worked with hadn't known they could just use boolean in JSON and had badly implemented it through strings, but this... This is amazing!

[–] jimmux@programming.dev 7 points 3 days ago

At my last job we had a lot of old code, and our supposedly smartest framework people couldn't be bothered learning front end properly. So there was a mix of methods for passing values to the front end, but nobody seemed to think of just passing JSON and parsing it into a single source of truth. There was so much digging for data in hidden columns of nested HTML tables, and you never knew if booleans would be "true", "TRUE", "1", or "Y" strings.

Never mind having to unformat currency strings to check the value then format them back to strings after updating values.

I fixed this stuff when I could, but it was half baked into the custom framework.

[–] sushibowl@feddit.nl 1 points 3 days ago

A system I work with gives all keys a string value of "Not_set" when the key is intended to be unset. The team decided to put this in because of a connection with a different, legacy system, whose developers (somehow) could not distinguish between a key being missing or being present but with a null value. So now every team that integrates with this system has to deal with these unset values.

Of course, it's up to individual developers to never forget to set a key to "Not_Set". Also, they forgot to standardise capitalisation and such so there are all sorts of variations "NOT_SET", "Not_set", "NotSet", etc. floating around the API responses. Also null is still a possible value you need to handle as well, though what it means is context dependent (usually it means someone fucked up).