72

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

IsSupportContentType

or

CanSupportContentType
21
  • 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, 2017 at 0:35
  • 10
    Not a native speaker but wouldn't DoesSupportContentType be the most "grammatical" option? May 10, 2017 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, 2017 at 8:40
  • 34
    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, 2017 at 9:12
  • 12
    @WeylandYutani IsCanHasSupportCheezburger?
    – R.M.
    May 10, 2017 at 13:36

3 Answers 3

127

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)
7
  • 61
    It's nice when it reads well: if ( someClass.Supports(contentType) ) May 9, 2017 at 23:28
  • 6
    …or hasSupportedContentType
    – Bergi
    May 10, 2017 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, 2017 at 13:10
  • 7
    Sometimes developers can't tell when something "sounds weird," e.g. if English is not their first language.
    – John Wu
    May 10, 2017 at 18:28
  • 10
    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, 2017 at 21:08
14

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
13
  • 27
    should is imho pretty poor naming, "well, it should close the document, but i'm actually not quite sure"
    – Lovis
    May 10, 2017 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, 2017 at 15:30
  • 1
    @greg How is that less ambiguous than WillCloseConnection?
    – Basic
    May 10, 2017 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, 2017 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, 2019 at 7:54
0

For the people against the use of "should" prefix for boolean arguments, here is my fresh last one used for an optional argument name (but I need to agree that I can't even remember last time I've used this prefix):

MethodNameToUpdateDataList(..., bool shouldDeactivateMissingIds = false) {}

Neither "is", "can" nor "will" prefix seems ok there... What do you think?

5
  • And I forgot about the "Are" and "Has" prefix.
    – Islem
    Nov 12, 2021 at 13:29
  • Another one: shouldAutoAllocateMovements. Whaou, none for years and two used in the same day :D
    – Islem
    Nov 12, 2021 at 14:28
  • Know I think that I understand, actually, most of the time, even with quite good coding practice when we use a boolean argument named without a standard prefix, we usually use directly the verb. Also meaning that, everytime we see a case like this, that means that it could have been prefixed with "should".
    – Islem
    Nov 12, 2021 at 23:17
  • What exactly does "should" indicate? Is there some logic behind this method that sometimes deactivates IDs? If not, the should prefix is redundant and misleading.
    – kiwiron
    Nov 22, 2021 at 6:40
  • @kiwiron: The anwser to your question: "Is there some logic behind this method that sometimes deactivate" --> is Yes ! That is why, the caller of this method has to decide (himself) or let default but, he can force to true in some cases. The method itself doesn't know yet when to do it or not, but the method still handle both logics. The caller is the one knowing when here.
    – Islem
    Feb 9 at 13:16

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