77

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

IsSupportContentType

or

CanSupportContentType
Martin Ba
  • 7,578
  • 7
  • 34
  • 56
Mediator
  • 839
  • 1
  • 7
  • 11
  • 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 Tullis May 10 '17 at 00:35
  • 1
    @Craig Unless the class is `ContentType` and some content types are support content types, of course - in which case `IsSupportContentType` would return true if the receiver is a support content type. But support**ed** is a different word entirely. – user253751 May 10 '17 at 01:11
  • 10
    Not a native speaker but wouldn't *Does*SupportContentType be the most "grammatical" option? – Roman Reiner May 10 '17 at 04:37
  • @RomanReiner That's already better grammar than more than one native speaker I know. :) – Craig Tullis May 10 '17 at 04:56
  • @immibis That is a fair point. I find myself compelled to agree with you, without inheritance or polymorphism even needing to necessarily play a part. – Craig Tullis May 10 '17 at 04:58
  • What kind of method are we even talking about? A getter type method or a query type method? Maybe a processing validation? – Weckar E. May 10 '17 at 08:07
  • 11
    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 08: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. – Olivier Grégoire May 10 '17 at 09:12
  • 1
    I agree with Olivier. `SupportsContentType` is the best choice. It is simpler, shorter, and reads better in a wider variety of statements. In general, when it's a toss-up like this, I look at how I expect the function to be called, and pick the one that ends up being the most readable with the surrounding code. The client of the library will either have to look it up or use IntelliSense anyway, so you might as well shoot for readability of the resulting code for future maintainers. – Cody Gray - on strike May 10 '17 at 09:27
  • 4
    You didn’t specify a language. [Standards vary widely](https://en.wikipedia.org/wiki/P_convention). – JDługosz May 10 '17 at 10:39
  • You can always use both. IsCanSupportContentType. I use both so that my code stands out. People know when I've been refactoring their code, they are delighted and I gain recognition. – Weyland Yutani May 10 '17 at 12:00
  • The capital first letters suggest that this is about C#, but it may be worth mentioning that for Java, there is another important point to consider: The `is` prefix is assumed for Java Beans, and expected by the introspectors. So in Java, you should usually use `is` as the prefix for "getters for `boolean` values". – Marco13 May 10 '17 at 12:40
  • 12
    @WeylandYutani IsCanHasSupportCheezburger? – R.M. May 10 '17 at 13:36
  • 3
    Conventions vary by language, and I'm surprised not to see a tag. For instance, in many LISP-family languages, the standard way to specify that a function has a boolean is to have its name end in a `?` -- so, `(defn support-content-type? ...)` – Charles Duffy May 10 '17 at 13:40
  • Best practice for boolean-returning methods/functions is [to not write them](https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/) in the first place. – leftaroundabout May 10 '17 at 14:12
  • 2
    `IsContentTypeSupported`? – daiscog May 10 '17 at 14:37
  • 1
    @WeylandYutani I'd be far from delighted if you'd renamed a method I'd written to something so horrendous. – daiscog May 10 '17 at 14:38
  • IsContentTypeSupported? – Toby May 10 '17 at 20:20
  • 1
    @megaflop He's gotta be onto *something* considering they've already cornered the synthetic market through superior engineering. – user253751 May 11 '17 at 08:19
  • I prefer a trailing `?`, or if that's not available, a trailing `-p`. (`p` for "predicate".) For benighted languages I use a prefix `p` or `q`. – davidbak Nov 13 '21 at 00:14
  • Has anybody else noticed how, over the years, this discussion has turned form „naming convention wars“ into a fruitful and respectful exchange of arguments as exemplified by this questions, it’s answers and it’s comments? – Hartmut Braun Nov 13 '21 at 08:30

3 Answers3

129

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)
John Wu
  • 26,032
  • 10
  • 63
  • 84
  • 62
    It's nice when it reads well: `if ( someClass.Supports(contentType) )` – candied_orange May 09 '17 at 23:28
  • 6
    …or `hasSupportedContentType` – Bergi May 10 '17 at 07: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
  • 1
    Could you add a TL;DR section that says, "Just name things so they read easily; stop worrying about it before you make it sound weird."? – jpmc26 May 10 '17 at 16:43
  • 7
    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
  • 12
    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
  • Has anyone used the "are" instead of "is" prefix? Ex: AreAllSelected vs IsAllSelected? I like the "is" but shouldn't I care about grammar? Or is there a better way to write them plurals? – Ε Г И І И О Oct 01 '21 at 09:20
17

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
Harry
  • 195
  • 3
  • 28
    **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
  • 2
    @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
  • @KRyan if you agreed on those things it' s cool. Conventions beat everything else – Lovis May 10 '17 at 19:44
  • -1 "Should" makes it sound like you're testing or asserting something. – Kevin May 10 '17 at 20:49
  • The "should" prefix is only acceptable because it's part of the framework's API. It only makes sense in react because react expects some components to have it. But in user land object oriented classes it doesn't make a lot of sense. React asks you (the creator of the class) if the component should update, but in framework-less code it doesn't happen that frequently. – Omri Luzon Oct 01 '18 at 21:41
  • How about "might" ? :) – lapin May 02 '19 at 07:45
  • 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 02 '19 at 07:54
  • "Should" is a completely valid prefix choice. There is no proper alternative to name a boolean which indicates whether the action should be executed or not. For example, ShouldDelete enables DB clean up. Just because it's longer than "Can" "Has" "Is", doesn't make it redundant or poor choice of words. Programming isn't a contest of variable shortening, they should be readable and easily understood. C++ std library is a great example of bad naming conventions, where you spend too much time reading the documentation. – HamsterWithPitchfork Feb 05 '20 at 11:36
  • 1
    @Lovis "Should" doesn't imply any uncertainty when used as a question, as it is here, i.e. "Should the component update?". "Should" seems like the best word to use for that question in plain English. – Bernhard Barker Mar 09 '20 at 14:59
  • Lovis, when the user clicks to close a window, MacOS asks the app whether it _should_ close the window. Are there unsaved changes? When the app tells a user about it, do they save changes, lose their changes, or cancel the close operation? So once you understand the situation, the naming makes perfectly sense. – gnasher729 Nov 12 '21 at 19:32
  • I've always considered anything in the right tense to indicate a question as fair game: `RequiresSupervisorPermission = MovingBackward || MovingMoreThanOne`. Sticking to only 'Is' as a prefix feels overly limiting, I'm interested in what others think – flumperious Jul 27 '22 at 13:28
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?

Islem
  • 1
  • 1
  • And I forgot about the "Are" and "Has" prefix. – Islem Nov 12 '21 at 13:29
  • Another one: shouldAutoAllocateMovements. Whaou, none for years and two used in the same day :D – Islem Nov 12 '21 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 '21 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 '21 at 06: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 09 '22 at 13:16
  • Why just not `deactivateMissingIds`? I don't want to tell it that it *should* do this thing. Just do the thing if it's relevant! – Vapid Aug 26 '22 at 07:15