48

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

IsSupportContentType

or

CanSupportContentType
  • 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." – Craig May 10 '17 at 0:35
  • 8
    Not a native speaker but wouldn't DoesSupportContentType be the most "grammatical" option? – Roman Reiner May 10 '17 at 4:37
  • 8
    First one would have to be IsSupportedContentType to be grammatically correct. (unless "support content type" acts as a noun, which seems unlikely) – CodesInChaos 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. – Olivier Grégoire May 10 '17 at 9:12
  • 10
    @WeylandYutani IsCanHasSupportCheezburger? – R.M. May 10 '17 at 13:36
103

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)
  • 53
    It's nice when it reads well: if ( someClass.Supports(contentType) ) – candied_orange May 9 '17 at 23:28
  • 5
    …or hasSupportedContentType – Bergi May 10 '17 at 7:07
  • 8
    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
  • 4
    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
7

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
  • 18
    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
  • 1
    @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
  • @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
  • @Basic At least in our case, will... is reserved for asynchronous functions that return a promise; if the function described in my previous comment is synchronous, using will... would be inconsistent with our naming. – KRyan May 10 '17 at 18:38

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.