I've seen some absolutely confounding names in recent code reviews. Sometimes you need to know if Godzilla exists! Do you:
const godzillaExists;
const doesGodzillaExist;
const godzilla;
Maybe it's more specific:
const godzillaExistsInStore;
const godZillaInStore;
const hasGodzillaBeenStored;
Top comments (8)
I prefer the first example in both cases. Specificity depends on the context. Does the function care about the "store" or not? Could Godzilla exist somewhere else, heaven forbid?
My go-to is to default to writing booleans in a way that makes them read more sentence-like in context. For example:
Hungarian notation is dead and good riddance to it, but formulating boolean names as
isX
orhasX
does a lot for clarity.Also, I prefer not to pass booleans to (typically multi-argument) functions unless they are obviously expecting true or false (ie. property methods), so typically "can" or similar named functions:
This is okay:
But this is not so good:
Some languages have named arguments, so in that case it'd be better to say:
Alternatively use enums:
usually something that makes grammatical sense paired with
if
if(userExists && userHasValidCredentials) { handeLogin(user) }
I'm also not worried about long variable names because VSCode fills them in for me, and most editors do that for you.
I usually use a variable with
is
as prefix, likeFor Ruby, and the humble question mark.
How would you feel about
godzilla?
At least they all follow camel casing
In that case I wouldn't use a boolean but an object. To check if it exists, I'd check if it's null or not.