Boolean method naming readability

Question

Simple question, from a readability standpoint, which method name do you prefer for a boolean method:

public boolean isUserExist(...)

or:

Answer 1

I would go with userExists() because 1) it makes sense in natural language, and 2) it follows the conventions of the APIs I have seen.

To see if it make sense in natural language, read it out loud. "If user exists" sounds more like a valid English phrase than "if is user exists" or "if does user exist". "If the user exists" would be better, but "the" is probably superfluous in a method name.

To see whether a file exists in Java SE 6, you would use File.exists(). This looks like it will be the same in version 7. C# uses the same convention, as do Python and Ruby. Hopefully, this is a diverse enough collection to call this a language-agnostic answer. Generally, I would side with naming methods in keeping with your language's API.

Answer 2

Why not rename the property then?

if (user.isPresent()) {

Answer 3

There are things to consider that I think were missed by several other answers here

1. It depends if this is a C++ class method or a C function. If this is a method then it will likely be called if (user.exists()) { ... } or if (user.isExisting()) { ... }
   not if (user_exists(&user)) . This is the reason behind coding standards that state bool methods should begin with a verb since they will read like a sentence when the object is in front of them.

2. Unfortunately lots of old C functions return 0 for success and non-zero for failure so it can be difficult to determine the style being used unless you follow the all bool functions begin with verbs or always compare to true like so if (true == user_exists(&user))

Answer 4

The goal for readability should always be to write code the closest possible to natural language. So in this case, userExists seems the best choice. Using the prefix "is" may nonetheless be right in another situations, for example isProcessingComplete.

Answer 5

Beware of sacrificing clarity whilst chasing readability.

Although if (user.ExistsInDatabase(db)) reads nicer than if (user.CheckExistsInDatabase(db)), consider the case of a class with a builder pattern, (or any class which you can set state on):

user.WithName("Mike").ExistsInDatabase(db).ExistsInDatabase(db2).Build();

It's not clear if ExistsInDatabase is checking whether it does exist, or setting the fact that it does exist. You wouldn't write if (user.Age()) or if (user.Name()) without any comparison value, so why is if (user.Exists()) a good idea purely because that property/function is of boolean type and you can rename the function/property to read more like natural english? Is it so bad to follow the same pattern we use for other types other than booleans?

With other types, an if statement compares the return value of a function to a value in code, so the code looks something like:

if (user.GetAge() >= 18) ...

Which reads as "if user dot get age is greater than or equal to 18..." true - it's not "natural english", but I would argue that object.verb never resembled natural english and this is simply a basic facet of modern programming (for many mainstream languages). Programmers generally don't have a problem understanding the above statement, so is the following any worse?

if (user.CheckExists() == true)

Which is normally shortened to

if (user.CheckExists())

Followed by the fatal step

if (user.Exists())

Whilst it has been said that "code is read 10x more often than written", it is also very important that bugs are easy to spot. Suppose you had a function called Exists() which causes the object to exist, and returns true/false based on success. You could easily see the code if (user.Exists()) and not spot the bug - the bug would be very much more obvious if the code read if (user.SetExists()) for example.

Additionally, user.Exists() could easily contain complex or inefficient code, round tripping to a database to check something. user.CheckExists() makes it clear that the function does something.

See also all the responses here: Naming Conventions: What to name a method that returns a boolean?

As a final note - following "Tell Don't Ask", a lot of the functions that return true/false disappear anyway, and instead of asking an object for its state, you tell it to do something, which it can do in different ways based on its state.

Answer 6

I like any of these:

userExists(...)
isUserNameTaken(...)
User.exists(...)
User.lookup(...) != null