Boolean method naming readability

Solution 1:

public boolean userExists(...)

Would be my prefered. As it makes your conditional checks far more like natural english:

if userExists ...

But I guess there is no hard and fast rule - just be consistent

Solution 2:

I would say userExists, because 90% of the time my calling code will look like this:

if userExists(...) {
  ...
}

and it reads very literally in English.

if isUserExist and if doesUserExist seem redundant.

Solution 3:

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.

Solution 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.