Which is the better name for a method that returns a boolean?
IsSupportContentType
or
CanSupportContentType
Asked
Active
Viewed 7.4k times
79
3 Answers
134
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,462
-
62It's nice when it reads well:
if ( someClass.Supports(contentType) )– candied_orange May 09 '17 at 23:28 -
6
-
9A 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
-
1Could 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
-
7Sometimes 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
-
12Sometimes 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 bystd::vector::clear(). But you must in general read the docs to be sure. As an opposite example, Qt'sQVectoris easier to understand in this regard, since its method of checking for emptiness isQVector::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
19
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
- 215
-
31should 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
-
2@Lovis We generally use
is...but useshould...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 thatisClosedwould be accurate (it’s not closed yet) and so we would useshouldCloseto 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, usingwill...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
-
-
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
-
-
1More 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
-
-
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
ContentTypeand some content types are support content types, of course - in which caseIsSupportContentTypewould return true if the receiver is a support content type. But supported is a different word entirely. – user253751 May 10 '17 at 01:11IsSupportedContentTypeto be grammatically correct. (unless "support content type" acts as a noun, which seems unlikely) – CodesInChaos May 10 '17 at 08:40supportsContentType? 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:12SupportsContentTypeis 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:27isprefix is assumed for Java Beans, and expected by the introspectors. So in Java, you should usually useisas the prefix for "getters forbooleanvalues". – Marco13 May 10 '17 at 12:40?-- so,(defn support-content-type? ...)– Charles Duffy May 10 '17 at 13:40IsContentTypeSupported? – daiscog May 10 '17 at 14:37?, or if that's not available, a trailing-p. (pfor "predicate".) For benighted languages I use a prefixporq. – davidbak Nov 13 '21 at 00:14