I wanted to share a recent thought about one specific naming topic and get your opinions on that: Using the 'is' prefix.
My point is that I feel the code is more readable without it most of the time.
const isValidResponse = validateResponse(response);
if (!isValidResponse) {
// ...
}
function getIsCheap(isFast, isGood) {
return !isFast || !isGood;
}
const isCheap = getIsCheap(true, true);
if (!isCheap) {
// ...
}
Versus:
const validResponse = validateResponse(response);
if (!validResponse) {
// ...
}
function getCheap(fast, good) {
return !fast || !good;
}
const cheap = getCheap(true, true);
if (!cheap) {
// ...
}
What do you think?
Do you use the 'is' prefix?
What do you think about prefixing a function with 'is' like isCheap()?
Update 1:
Still in doubt about using is
for variables. I am convinced that it is great for functions though.
Arguments for using is
for variables:
- In case it is an existing naming convention for the project
- Knowing it is boolean
- Easier to search for isValue then for value
- For class properties like user.isLoggedIn
My example with updated function names (I like how it reads):
const validResponse = isValidResponse(response);
if (!validResponse) {
// ...
}
function isCheap(fast, good) {
return !fast || !good;
}
const cheap = isCheap(true, true);
if (!cheap) {
// ...
}
Update 2:
I ended up using the is
prefix after all. The thing I like most about it is the fact that I can immediately see that the value is a boolean.
Top comments (32)
Use prefix
are
orhas
oris
if variable contains boolean. Use prefixthe
(or not at all, as long as variable name represent a noun) if variable contains data.Imagine you have a component
<FancyButton>
what interface would you expect/prefer?<FancyButton disabled dark>
or<FancyButton isDisabled isDark>
?For me it is definitely the first and for the implementation it would look odd to stick to naming the variables isSomething.
For example:
For the hasValue part: If hasValue is used once (or twice) and is as simple as
!!value
orvalue != null
I would go with the expression. Arguing that hasValue is vague, and I might still end up having to read the definition of hasValue.Can you come up with downsides of writing your code like this:
?
I am searching for some solid arguments against never using thje 'is' prefix.
The
<FancyButton>
is a different case. I'd agree to write it as<FancyButton validated>
instead of<FancyButton isValid>
. Because it's a pattern used by everyone, so it'll give a clearer understanding.Maybe narrow the prefix "is" only for JS identifier. Or make an exception for property names that can be used as JSX attribute then prefix "is" are not allowed. Just info, three.js use prefix "is" in their class properties.
Yes, it has a great readability for class properties as well.
if (object.isCamera) { // ... }
I can’t even come up with another way to name isCamera without
is
.Most of the time it is just about efficiency in searching/replacing things via code editor. When you type “value” in search box, you will get too many results.
I prefer the is-prefix to without it. But I'd write it as follow:
This gives clearer call-to-action function naming to me. Also I'd never write
getIsCheap()
, butisCheap()
instead. But whatever you choose, the most important thing is to stay consistent.Yeah, I get your point and I do have a fair amount of functions starting with is.
One problem I run into is naming the result of an is prefixed function.
I obiously can’t write:
What I can do is:
I tend to like the first one the most.
You can do so by writing:
Because
isCheap()
is a generic function, I think it'd be useful to make the context of your code clearer.This discussion remind of prefix
I
in interface (i.eIDispose
). In my journey, there is 2 times when I debate this with my peer. The first one is when we refactor our JS code into Typescript and the second one is when exploring Rust. Now I just follow the majority in that language ecosystem whatever it makes sense or not.Follow the majority is quite a safe bet if it is clear what the majority does :-) Same is valid for codebase conventions and existing code. I would use
is
without a second though if there is anotherisVariable
in the same space.If I would work together with someone and there would be a debate about using
is
for boolean variables I hope I would just give in. I like how much cleaner it looks without but this is such a trivial detail in the end. But I love to explore this topic!I really like this convention! It flows a lot better when reading through code, resembling a real language. I tend to use the
is
,has
, andare
prefixes as @taufik_nurrohman also pointed out. Although I prefer making them functions or methods instead of variables, as you also mention in some other comment. Otherwise it can get confusing. IsisEmpty
a method or a variable...Good point, I also like the readability of 'is' prefixed funtions. I am still sceptical if prefixing variables with 'is' is worth it. It might just be me, but I like the subtle more clean looking code without.
I don’t like the second version, it looks so ew.
But for the function
isCheap()
instead ofgetCheap()
reads so much better I have to admit.This is precisely why we often end up with methods like
isNotEmpty
as convenience methods in places whereisEmpty
exists - because!thing.isEmpty()
not only reads weirdly, but a code reviewer might not even spot the!
because of the way it reads.prefixes are useful conventions when working with large codebases in a highly collaborative environment. I have authored many methods with
is
as a prefix for evaluating conditional actions. I've also usedhas
as a prefix as well for iterating over a collection to evaluate a conditional.is
(andhas
) for functions is nice, I can’t argue against that.I agree with @katafrakt on this:
The
is
prefix lets us see at-a-glance that the value is a boolean, whereas it's not so easy to tell at-a-glance whether a value is a boolean, so addingis
orhas
offers value.(Old-school VB coders would have gone further and prefixed variables with
i
for integer, etc. However I think this is taking it too far. It's usually easy to tell at-a-glance whether a value is a number. E.g.year
is very likely to be a number, so addingiYear
wouldn't offer much value.)As @katafrakt mentions,
validResponse
might refer to:Even worse - for the false/empty state, it could be used as a boolean. For example,
data
returned byuseQuery
in react-query can beundefined
or have the data.Example:
My suggestion is to prefix all booleans with
is
,has
,can
, etc.However – where possible, it's better to use a more informative type than boolean, such as enum, object, etc. A richer type can convey more information about the state than just true/false.
hasValue: false | true
-false
only tells us whether it's empty, but doesn't tell us whyvalue: number | null | "unset"
-null
tells us whether it was deliberately cleared or never set in the first placeThanks for your comment. Agreed.
I ended up using the is prefix after all :)
The convention in Kotlin is for boolean properties to start with
is
. This extends to its automatic recognition of properties in Java classes - if a class has anisCheap
andsetCheap
method then it will automatically get aisCheap
var. This seems to be a common convention in C# as well.In Java I usually would not do it - there, it's conventional for the getter method to be called
isCheap
while the backing boolean is just calledcheap
.So which one to use is entirely going to depend on what language I'm writing.
For functions, I think it depends as well.
If it were
isCheap(thing)
then I'd keep the nameisCheap
. Actually, I would try to refactor it such that it's just anisCheap
property onThing
if possible. But if I'm working in something functional where I can't really do that, sure -isCheap(thing)
makes some sense. But in the current form in that example, I'd probably call itdetermineIsCheap
or similar - the thing being passed in isn't the thing where you're determining whether it's cheap, but more a collection of other properties about some object which is not itself provided.Interesting, thank you!
I stumbled upon this article a few days ago michaelzanggl.com/articles/tips-on... . Also, if you are using typescript there is worth to setup typescript-eslint rule:
I am still not on the
is
for variables side… But I like this example from the article:Maybe it is a little different for class properties as well.
I like the way you chosen with using of prefix ‘is’ only for functions.
I change my mind about it fairly frequently in practice, but in theory my thinking is the following: verb prefixes imply predicates or instructions, which means it should be a function (or a toggle flag). That said, booleans are tricky - it never quite "feels" right to have an unprefixed variable representing a boolean.
validResponse
is the valid response, right? Oh, wait.This is true, could be the valid response as well. I think this level of ambiguity might not be problem, it happens quite often in code. I would argue it’s not the job of the variable name to tell me its type.
There is still the issue with naming the result when the function has the name already:
One idea would be to name it
responseIsValid
. I still prefer responseValid if the context allows for it.