I mean aside of the variable name, this is not entirely unreasonable.
post
Ah, the ol' tristate boolean switcheroo
tristate as in three states or tristate as in five states?
Classic checkbox values
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.
Sadly this is (or used to be) valid in PHP and it made for some debugging “fun”.
What if role is FILE_NOT_FOUND?!
if it's 'FILE_NOT_FOUND' then the string will be read as truthy and you will get 'User is admin' logged.
i would say why would you just not to isAdmin = true but 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.
That's terrifying, especially in JS where no type system will fuck you up for returning nothing when you should've returned a boolean.
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 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.
Fair enough, I like it better without but I don't have a strong preference and have no issue adapting to whatever the style of the repo is.
I learned about it researching tools to automatically enforce formatting style and came across StandardJS, which eliminates them by default.
I can see the benefit of matching style when working with others. I only code for myself and never had to worry about conformity for project consistency.
It is good to learn new things.
I'm sure I have some coding habitats that would annoy others.
Hmm, a webdev colleague said he'd normally prefer without semicolons, but used them anyways for better compile errors.
Interesting, I'm not aware of any way they would affect compile errors. I'd be curious to know more.
I don't have experience with how it affects JavaScript specifically, but independent of programming language, it usually removes the guesswork where the error might be.
The thing is that compilers use fairly static rules for their grammar. So, even if you just typo a comma where there should've been a dot, then its grammar rules don't match anymore and it doesn't really know what to do with your code.
To some degree, it's possible to say certain symbols just cannot appear in a specific place, but especially with a comma, it could be the start of the next element in a list, for example.
Without semicolons, it's likely going to tell you that something's wrong between somewhere before your typo and the next closing brace (}). With semicolons, it can generally pinpoint the specific statement where the comma is wrong.
This should also make analysis quicker while you're editing the code, as it only has to check one statement (or two, if you're inserting a new line and haven't typed the semicolon yet).
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
And what if it's undefined?
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?
a === b returns true if a and b have the same type and are considered equal, and false otherwise. If a is null and b is a boolean, it will simply return false.
The logic is fine. If you rename the variable to isAdmin, it makes perfect sense. Either they are an admin, or they are not an admin, or the state is unknown (here expressed as null). If you want to throw another JS-ism at this, undefined could be assigned before the check has been made.
I regularly use variables like this. If users is undefined, I haven’t fetched them yet. If they’re a list, then fetching is complete. If they’re null, then there was an error while fetching.
The only flaw is that the console.log states that null means user is not logged in.
If there are three or more explicit states, you should not use a nullable bool, but some more explicit data structure, like enum.
For example, if the state comes from a db, the user could be successfully logged in, but somehow for a range of possible reasons this variable ends up as null and you'll have a hell of a time debugging, because the log will give you nonsense.
Today i have seen:
if (var === true || var === 'true' || var === "true")
I'm just fortunate enough to not work with the frontend at our very backend service, but I always hear things that shouldn't be even allowed in this planet.
How many "equal" symbols do we need to be absolutely sure?
Obviously this should be a Result that the gets compiled to a nullable bool.
Aren't the first two if branches completely useless? The variable was just defined without a value, so it should always be null
the real crime in this photo is the ===
I'm so confused. I understand the reasoning behind two equal signs but three?
all 67 comments