I like the practice of naming boolean variables with a prefix like "is", "has", "should", or "can".

But what about the functions that produce those results?

Currently I'm using:

const isReadyForPublicProfile = checkWhetherIsReadyForPublicProfile(teacherOf);
const shouldWarnAboutProfileChangingToPrivate =
    checkWhetherShouldWarnAboutProfileChangingToPrivate(isDirty, teacherOf);

What is the best practice for naming the function?

2 Answers 2


There is no universal practice to name functions that return Booleans, because such Boolean results can have a broad variety of purposes. The main naming rules are to use names that reveal the intentions, be consistent, and avoid names that are too long.

Some authors proposed popular recommendations:

  • Steve McDonnel's popular Code Complete suggests the list that you have "is", "has", "should", or "can", but for variable names. You can easily extend it to method names, since R.C. Martin recommends to use a verb or a verbal phrase for method names, which is not incompatible with those prefixes.

  • Stephen Colebourne, a contributing expert to the Java JSR standardization process, proposed a list for method prefixes in a 2011 article in which there is only is that has an explanation referring to Boolean results. By the way, his list made it into the official Java tutorial

Interestingly, in view of the prefix in the above list, your naming would be ambiguous:

check: Checks if something is true, throwing an exception if it is not true. Example foo.checkValid().

Get rid of the checkWhether prefix. You could for the variable even get rid of the prefix:

const readyForPublicProfile = isReadyForPublicProfile(teacherOf);
if(readyForPublicProfile) {
  • In TypeScript, I strongly prefer prefixing boolean variables with a prefix like "is", "has", "should", or "can". It's nice to know without needing to hover or explore anything that the variable is boolean. And the guideline of "use a a verb or a verbal phrase for method names" is something that makes sense to me, which is why I named the functions the way I did. +1 for your answer. I appreciate the thoughts and links!
    – Ryan
    May 16 at 23:25

Your function names are very long, and the “checkWhether” doesn’t contribute anything of value. So the function names should be “isReadyForPublicProfile” and “shouldWarnAboutProfileChangingToPrivate”.

  • In TypeScript, I can't have functions that are the same name as the constant whose value I'm assigning as the result of the function. I don't mind long function names if it is necessary for clarity.
    – Ryan
    May 16 at 22:05
  • 5
    @Ryan: If you cannot have both, then keep function names starting with "is" or "should" and use other names for local variables instead. E.g. you can use abbreviations for local variables, like "isReady" and "shouldWarn", because their meaning is easily understandable from the context.
    – mentallurg
    May 16 at 22:27
  • is, has, should and can generates cognitive burden. I know, because I used them too. While I also like them (overall for methods), short and concise var names are going to be always superior because they won't make devs fall asleep. So, in Typescript or in any other language ready or publishable are fairly better than isReadyForPublicProfile because the boolean var's scope is (ideally) local and whatever they are ready for is implicit in the scope.
    – Laiv
    May 17 at 7:37
  • 2
    @Laiv, for me "is", "has", "should", "can" have very, very specific meanings that shouldn't be removed.
    – gnasher729
    May 17 at 15:39
  • 1
    @Ryan: Coming up with variations just because you want to avoid collisions means that you are setting yourself up for a guessing game of "what variation did I use here?" for the maintenance phase. Don't. Pick a name that unambiguously describes the purpose, and pick the most obvious name that someone can reasonably think of/understand when they maintain this code.
    – Flater
    May 18 at 4:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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