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)
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:
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:
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.
For Ruby, and the humble question mark.
How would you feel about
godzilla?
I usually use a variable with
is
as prefix, likeIn 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.
At least they all follow camel casing