Which is the better name for a method that returns a boolean?



  • 9
    Since the intent is for the name to clearly convey state or behavior, and you would never say "this class is support content type X," the better name is CanSupportContentType. You would say something like "this class can support content type X." May 10 '17 at 0:35
  • 9
    Not a native speaker but wouldn't DoesSupportContentType be the most "grammatical" option? May 10 '17 at 4:37
  • 11
    First one would have to be IsSupportedContentType to be grammatically correct. (unless "support content type" acts as a noun, which seems unlikely) May 10 '17 at 8:40
  • 30
    What about simply supportsContentType? The following is entirely readable: if (abc.supportsContentType("text/html")). "can support" implies that there are further conditions to support the content-type. May 10 '17 at 9:12
  • 10
    @WeylandYutani IsCanHasSupportCheezburger?
    – R.M.
    May 10 '17 at 13:36

Is vs. Can

According to the Microsoft naming convention recommendations, both "Is" and "Can" are OK (and so is "Has") as a prefix for a Boolean.

In plain English, "Is" would be used to identify something about the type itself, not what it can do. For example, IsFixed, IsDerivedFrom, IsNullable can all be found in CLR types and methods. In all of these cases, "Is" is followed by an adjective.

Meanwhile, "can" more clearly indicates a capability, e.g. CanEdit, CanRead, CanSeek. In each of these cases, can is followed by a verb.

Since "Support" is a verb, I think in your case CanSupportContentType is better.

Shorter alternative

On the other hand, the conventions say the prefix is optional. What's more, it's kind of cheesy to include the argument type in the method name, since a developer can see the type of the argument in intellisense. So you could just name your method Supports and define it like this:

public bool Supports(System.Net.Mime.ContentType contentType)

...which is shorter and still clearly communicates the purpose. You'd call it like this:

ContentType contentType = new ContentType("text/plain");
var someClass = new MediatorsClass();
bool ok = someClass.Supports(contentType);

Or as a compromise maybe this is best:

public bool CanSupport(System.Net.Mime.ContentType contentType)
  • 59
    It's nice when it reads well: if ( someClass.Supports(contentType) ) May 9 '17 at 23:28
  • 6
    …or hasSupportedContentType
    – Bergi
    May 10 '17 at 7:07
  • 9
    A method called "CanSupports" initiallty mades me wonder who spent time to make the software able to support cans (as in tin cans). Just "Supports" is the better option, no doubt!
    – T. Sar
    May 10 '17 at 13:10
  • 6
    Sometimes developers can't tell when something "sounds weird," e.g. if English is not their first language.
    – John Wu
    May 10 '17 at 18:28
  • 9
    Sometimes a shorter version is worse. E.g. in the C++ Standard library we have std::vector::empty(). From its name only, does it empty the vector? Or does it return whether the vector is empty? Actually the latter, since the former task is done by std::vector::clear(). But you must in general read the docs to be sure. As an opposite example, Qt's QVector is easier to understand in this regard, since its method of checking for emptiness is QVector::isEmpty().
    – Ruslan
    May 10 '17 at 21:08

It's worth mentioning that the "should" prefix can also be used. According to Apple's guideline, not just "can" and "should", modal verbs in general can be used to name functions that return boolean. I can't see many use of "will" but "should" is nice for advice-inquiring hooks, as seen in reactjs:

shouldComponentUpdate: (newProps: any) => boolean
  • 25
    should is imho pretty poor naming, "well, it should close the document, but i'm actually not quite sure"
    – Lovis
    May 10 '17 at 13:13
  • 4
    @lovis: I think Harry's comment is very valid. For example, I could delegate some database-related actions through a plugin layer, each plugin has a "ShouldCloseConnection" method which informs the framework that some cleanup should be performed. Just an example, but "should" is definitely a valid prefix.
    – greg
    May 10 '17 at 15:30
  • 1
    @greg How is that less ambiguous than WillCloseConnection?
    – Basic
    May 10 '17 at 17:37
  • 1
    @Lovis We generally use is... but use should... in some function argument names, places where the boolean indicates what the function is supposed to change things to. If a function can optionally close a document, calling the parameter controlling that isClosed would be accurate (it’s not closed yet) and so we would use shouldClose to indicate that this is what the function is supposed to do. (Arbitrary example; we wouldn’t likely have a function like this, particularly since closing a document should be weighty enough to have a dedicated call.)
    – KRyan
    May 10 '17 at 18:36
  • 1
    More seriously, how would you prefix a boolean for some element that has to show, to be displayed: myButton.shouldShow, anything else?
    – lapin
    May 2 '19 at 7:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.