Same as ?
std::optional<bool> role; if (role.value()) { std::cerr ("User is admin");} else if (!role.value()) { std::cerr ("User is not admin");} else if (!role.has_value()) { std::cerr ("User is not logged in");}Here
has_value()should have been checked first, but the JS seems kinda fine.
Which is it?I see this every sprint.
Sadly this is (or used to be) valid in PHP and it made for some debugging “fun”.
There are several small details that PHP won’t allow, but It’s valid Javascript and it’s the kind of thing you may find on that language.
I mean aside of the variable name, this is not entirely unreasonable.
I would certainly rather see this than
{isAdmin: bool; isLoggedIn: bool}. Withboolean | null, at least illegal states are unrepresentable… even if the legal states are represented in an… interesting way.Product manager: “I want a new role for users that can only do x,y,z”
Developer: “uh… yeah. About that… Give me a few days.”
Yeah let’s use a union of a boolean and null to represent role, something that inherently represents more than two (…or three, I guess) different values, as opposed to something like an integer.
Even if the name is clearly misleading in this specific case, the entire choice of using a bool here is just bad because it’s almost guaranteed you’re going to expand on that in future and then you’ll just have to entirely rewrite the logic because it simply can’t accommodate more than two values (or three with the null union… 🙈), while it gives absolute zero benefits over using something more reasonable like an integer to represent the roles, or in this case, admin, not-admin and guest. Even if you’ll end up with just admin, non-admin and guest, the integer would still work great with no disadvantages in terms of amount of code or whatever. Just increased legibility and semantical accuracy.
Not to mention that there’s zero reason to combine the state of being logged in and the role in which you’re logged in in one variable… those are two different things. They will remain two different things in future too…
I mean they’re already chaining elseifs (basically matching/switching, while doing it in an inefficient way to boot 🥴) as though there were an n amount of possible states. Why not just make it make sense from the start instead of whatever the hell this is?
This is quite reasonable, aside from the variable name which should be
isAdmin. A user either is an admin, or isn’t. Unless we don’t know, then it’s null. You are correct this is bad if the point was to represent roles, but it’s not supposed to.Admin is a role though, was my point. And besides, if you check for three different states, and you decide to go with a boolean to represent that, I really find it hard to believe anyone would think it reasonable. It’s valid and it’s practical, but can you really say it’s reasonable?
I don’t do typescript, but wouldn’t a union of a null and a bool be just more resource intensive than simply using an unsigned byte-sized integer? I struggle to find reasons to ever go for that over something more reasonable and appropriate for what it attempts to represent (3 distinct states as it stands, and likely in future more than just 3 when they have a need for more granularity, as you’d often do with anything you’d need an admin role distinction in the first place), but likely I’m just not familiar with ts conventions. Happy to hear the reasoning for this though.
So in a language with nullable types, are you against a boolean ever being nullable? Null means “empty, missing info”. Let’s say we have
rolevariable with a enum type of possible roles. It could still reasonably be nullable, because in some scenarios you don’t know the role yet, like before log in.In any use case where we need to store some boolean, it’s a common occurrence that we don’t have the data and it’s null. It would be overkill to use an enum with
True,False,NoDatafor these cases, where there is already a language feature made just for that, nullable values.I’ve never used TypeScript, just writing from experience in other languages.
Yeah, but if it is about being an admin or not, hence the bool, it’d be idiomatic and reasonable to assume it to be false if we have no data. Unless we want to try and allow admin access based on no data. Having three states for a simple binary state is weird. And if it is not about just being an admin or not, the bool is inherently a too limited choice for representation.
E: omg forget my whole comment. I agree with you that the name sucks.
I mostly don’t like that
roleis typically an intuitive name, and now suddenly it means something I wouldn’t expect. Why add confusion to your code? I don’t always remember what I meant week to week, much less if someone else wrote it.If I had a nickel for every time that happened to me, I’d still be poor, but at least I’d have several nickels. 😁
Ah, the ol’ tristate boolean switcheroo
i would say why would you just not to
isAdmin = truebut i also worked with someone who did just this so i’ll instead just sigh.also the real crime is the use of javascript tbh
That’s TypeScript. I can tell by the pixels defining a type above.
Was looking at it and could not figure out why their weren’t any semicolon’s.
Neither Javascript nor Typescript require semicolon, it is entirely a stylistic choice except in very rare circumstances that do not come up in normal code.
Explanation for nerds
The reason is the JS compiler removes whitespace and introduces semicolons only “where necessary”.
So writing
function myFn() { return true; }Is not the same as
function myFn() { return true; }Because the compiler will see that and make it:
function myFn() { return; true; }You big ol’ nerd. Tee-hee.
Common JavaScript L
Not wrong, but funnily enough, it’s a linting rule win. I’d go nuts if I didn’t have my type checks and my linters. My current L, though, is setting up the projects initially and dealing with the configuration files if I raw dog it, but that’s a problem with ESLint configs and the ecosystem as a whole having to deal with those headaches. So in the end, the JS devs got clever and shifted the blame to the tooling. 😅
That’s terrifying, especially in JS where no type system will fuck you up for returning nothing when you should’ve returned a boolean.
Hmm, a webdev colleague said he’d normally prefer without semicolons, but used them anyways for better compile errors.
That’s good to know. Don’t know how I didn’t know this. Been writing JS since 2000. Always just used them I guess. Ecmascripts look funny to me without them
Same here. My brain interprets them as one long run-on sentence and throws a parsing error.
This is pretty clearly just rage bait. Nothing is actually setting the value so it’s undef. Moreover there isn’t any context here to suggest if the state definitions are determined by some weird api or are actually just made up
Troof
I mean facts. Facts is what the kids say. Facts.
*Fax
Dammit!
We don’t use fax machines any more grandad! It’s all twoggles now! Twoggle me a nurp!
What if
roleisFILE_NOT_FOUND?!if it’s
'FILE_NOT_FOUND'then the string will be read as truthy and you will get'User is admin'logged.Ackshually three equal signs check for type as well. So mere truthiness is not enough. It has to be exactly true.
Also, everyone knows FILE_NOT_FOUND isn’t a string but a boolean value.
role is never instantiated, so the… privileged…logs… will never be called
Edit: Actually no logs at all, I read the null as undefined on first skim
What the fuck
