291
True crime
(europe.pub)
And what if it's undefined?
You could make it even dumber by using weak comparisons.
I see this every sprint.
I mean aside of the variable name, this is not entirely unreasonable.
The variable name is 90% why this is so unreasonable. Code is for humans to read, so names matter.
I would certainly rather see this than {isAdmin: bool; isLoggedIn: bool}. With boolean | null, at least illegal states are unrepresentable... even if the legal states are represented in an... interesting way.
Admin false LoggedIn false doesn't feel illegal to me, more redundant if anything
I was thinking of the three legal states as:
- not logged in (
nullor{isAdmin: false, isLoggedIn: false}) - logged in as non-admin (
falseor{isAdmin: false, isLoggedIn: true}) - logged in as admin (
trueor{isAdmin: true, isLoggedIn: true})
which leaves {isAdmin: true, isLoggedIn: false} as an invalid, nonsensical state. (How would you know the user's an admin if they're not logged in?) Of course, in a different context, all four states could potentially be distinctly meaningful.
ah you are right! i am so dumb.
Honestly logged in is state and shouldn't be on the user object.
load more comments
(13 replies)
Ah, the ol' tristate boolean switcheroo
tristate as in three stages or tristate as in five states?
That is the jankiest thing I have seen in at least ten years.
Edit: because of course it's office.
Is that a quantum boolean?
Robert Martin is screaming somewhere. Say what you will about him being out of touch, he did have some good points on writing readable code.
Like null should never be a special value.
And obviously the horrible naming.
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.
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
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.
load more comments
(1 replies)
load more comments
(2 replies)
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.
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
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.
I see, so logically it is fine.
Just not in the context.
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.
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.
yeah, it's funny how my brain collapsed the boolean check into if (role) rather than if (role === true) - that's tricky
what is FILE_NOT_FOUND? I can't find much on it ...
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.
view more: next ›
this post was submitted on 14 Aug 2025
291 points (96.2% liked)
Programmer Humor
25726 readers
1258 users here now
Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Rules
- Keep content in english
- No advertisements
- Posts must be related to programming or programmer topics
founded 2 years ago
MODERATORS