True crime
-
Ah, the ol' tristate boolean switcheroo
wrote last edited by [email protected]tristate as in three states or tristate as in five states?
-
tristate as in three states or tristate as in five states?
Is that a quantum boolean?
-
This post did not contain any content.
And what if it's
undefined? -
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
wrote last edited by [email protected]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.
-
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.
-
tristate as in three states or tristate as in five states?
wrote last edited by [email protected]That is the jankiest thing I have seen in at least ten years.
Edit: because of course it's office.
-
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.
-
FILE_NOT_FOUND is from an old story on thedailywtf.com. Someone created a boolean enum with TRUE, FALSE and FILE_NOT_FOUND, if I recall correctly. It's been a recurring running joke.
thank you for letting me in on the joke
and for catching my error!
-
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.
Consistent styling helps make the actual meaningful changes easier to spot. Probably also useful for your own commit history when working solo in a repo, but most useful in a team, yeah!
-
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). -
And what if it's
undefined?root access
-
thank you for letting me in on the joke
and for catching my error!
Welcome! I guess this is your Ten Thousand moment for a mediocre joke for old programmers.
-
Ah, the ol' tristate boolean switcheroo
Classic checkbox values
-
Classic checkbox values
Yup. Checked, unchecked, and not checked.
-
Welcome! I guess this is your Ten Thousand moment for a mediocre joke for old programmers.
haha, yes - exactly! At least I got that reference, xkcd is pretty well known, though.
-
haha, yes - exactly! At least I got that reference, xkcd is pretty well known, though.
I see that they've gone back to the name "The Daily WTF". For some time, they changed to "Worse than failure" in order to avoid not even the word "fuck".
-
I donāt really follow you there, wouldnāt it be exactly the opposite and wouldnāt checking for nulls be, as a premise, more wasteful? But doesnāt really matter, time to digress. Iām conventionally educated as an engineer so what I know and find reasonable today might be outdated and too strict for most contemporary stuff.
Let's say you have a website receiving 1 million requests per day. 0.01% of those are admin requests that need to know if your are an admin to execute them. It would be wasteful to check with the database if you are an admin for every request, when only a tiny minority of then needs to know that. So for 999.900 of the requests
isAdminwill benull. We don't know if the user is an admin and we don't need to know. -
Let's say you have a website receiving 1 million requests per day. 0.01% of those are admin requests that need to know if your are an admin to execute them. It would be wasteful to check with the database if you are an admin for every request, when only a tiny minority of then needs to know that. So for 999.900 of the requests
isAdminwill benull. We don't know if the user is an admin and we don't need to know.wrote last edited by [email protected]That all is besides the point. Thereās no real advantage to use null instead of defaulting to false thereā¦ itās semantically more accurate and also less wasteful in that other code does not have to worry about nulls which always leads to unnecessary overhead when false is already equivalent in your proposed example.
-
That all is besides the point. Thereās no real advantage to use null instead of defaulting to false thereā¦ itās semantically more accurate and also less wasteful in that other code does not have to worry about nulls which always leads to unnecessary overhead when false is already equivalent in your proposed example.
wrote last edited by [email protected]It is not more accurate nor less wasteful. If you default it to
falseand you have 100 admin requests in the session where that variable is stored, you would have to check with the database 100 times. Because you are conflatingfalseto mean two things: "the user is not an admin" and "we don't know if the user is an admin". Where if you set it totrueorfalsethe first time we need the information, then subsequent requests don't need to check anymore.does not have to worry about nulls
I am used to null safe languages where there is no such thing as worrying about nulls, because not checking for null on a nullable type is a compile error, and so it's impossible to forget about the null case. Maybe it's why I don't see any issue with using them.
-
It is not more accurate nor less wasteful. If you default it to
falseand you have 100 admin requests in the session where that variable is stored, you would have to check with the database 100 times. Because you are conflatingfalseto mean two things: "the user is not an admin" and "we don't know if the user is an admin". Where if you set it totrueorfalsethe first time we need the information, then subsequent requests don't need to check anymore.does not have to worry about nulls
I am used to null safe languages where there is no such thing as worrying about nulls, because not checking for null on a nullable type is a compile error, and so it's impossible to forget about the null case. Maybe it's why I don't see any issue with using them.
That is all just external implementation details. Not sure if it was you or someone else, but the main argument in defense of the OP as in it reasonable, was that the name is wrong. That it ought to be idAdmin. None of what you just described should have anything to do with user being or not being an admin. In place of checking āisAdminā for null, the semantical and resourcewise equivalent would be a third variable for āadmin rights having been validatedā or whatever. Conflating it in this one variable while renaming it to isAdmin or similar, would be even less sensical.. what if somewhere else in the code you have to check whether the initial validations have been made (while the actual role or whether is admin or not is irrelevant), youād have to check if isAdmin equals null, which in that context would be confusing, ambiguous (i.e someone reading that bit will not know this is what is being checked without additional documentation) and just a code smell in general. You do want to make the important things unambiguous and self-documenting. Even more so the bigger the codebase is and the more contributors there are across its lifetime and in parallel at any given time.
But if we go with the original meaning of roles overall, then the union type is just a code smell that warrants a proper role thing around it.
