Original post: hachyderm.io (Mastodon)
So we need to be careful with upper- and lowercase. Meanwhile the docs: > settiings
Yes, the settiings are different than the settings. You also need to be careful with those.
Is the backend Python and the frontend JavaScript? Because then that would happen and just be normal, because Boolean true is True in python.
Probably, but if you’re interpreting user inputs as raw code, you’ve got much much worse problems going on, lol.
It’s the settiings file… It’s probably supposed to only be written by the system admin.
A good place to put persistent malware. That’s why when using docker images always mount as ro if at all possible.
Given the warning about capitalization, the best possible case is that they’re using ast.literal_eval() rather than throwing untrusted input into eval().
Err, I guess they might be comparing strings to ‘True’ and are choosing to be really strict about capitalization for some reason.
In this instance, I think there was some suggestion to write code in mostly lower case, including all user variables, or at least inCamelCaseLikeThis with a leading lower case letter, and so to make True and False stand out, they’ve got to be capitalised.
I mean. They could have been TRUE and FALSE. Would that have been preferable? Or how about a slightly more Pythonic style: __true__ and __false__
Depends on how it’s set up. If the setting is going into the env it’s a string, so I’d expect some sort of
if os.getenv("this_variable", "false").lower() == "true": # or maybe "in true, yes, on, 1" if you want to be weird like yaml
this_variable = True
else:
this_variable = False
Except maybe a little more elegant and not typed on my phone.
But if the instructions are telling the user to edit the settings directly, like where I wrote this_variable=True, they’d need to case it correctly there.
Fyi, using a condition to assign a boolean is equivalent to assigning the condition itself. No need for the IF.
I refer you to #7 on Bruce Tognazzini’s evergreen top ten list of design bugs.
Could be worse. At least it’s documented
How about this:
Humans (or humans assisted by AI) write documentation
Users (devs included) can either choose to read the manual the old fashioned way or utilize it like a sort of swagger api documentation to give
- Information to a question (How to do x)
- Provide a general example
- (Assuming it’s used with an IDE or has information about the project) Provide a personalized example on the implementation.
I’ve had pretty good experience with using AI to find what I’m looking for in documentation, especially if the docs are in context
The cherry on top is that they didn’t even spell settings correctly.
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!
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.
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).
