Whenever I do my Code Review workshop, I spend a few minutes going over some minor code smells that I believe are more or less universally aplicable. One of these is to avoid functions named “Check”.

Why?

Because the intention is rarely clear.

For example, suppose you see a function named CheckFoo(). What does this function do? I don’t know.

• Does it throw an error if a passed foo value is invalid?
• Does it return a boolean indicating the validity of foo?
• Does it check some other resource against the passed foo object?
• Does it return some status object about foo?
• Does it kick off some sort of status check in the background? How would I get the results?

Depending on your language, some of these questions may be answered by the function signature. I.e. if you know it returns a boolean, we can guess that it’s the second or third option, but that’s still not very specific.

So what’s the alternative?

Simply use a more descriptive name.

If it’s validating data, maybe FooIsValid(), returning a boolean, is a good choice. There’s no ambiguity there.

If you want to return more than a boolean from your validation function (such as a description of the validation failure), perhaps consider ValidateFoo() which throws an error or returns a descriptive text/object on failure.

Maybe you’re checking whether an external resource described by foo is accessible? IsFooAccessible() might work.

All this to say, there’s no single correct way to name your functions. But Check is usually a wrong way, for the simple reason that it’s so ambiguous.