Prefix "Is" in Method Name for Verification Methods

Question

I've been reading Code Complete lately, based off of many references here and also by a friend, and had a naming question for the community. Should the prefix "Is" be used on boolean methods that determine whether an event was successful? Here is a code example of two different naming schemes I tried:

migrationSuccessful = CopyData();
if (VerifyCopyData())
   migrationSuccessful = CleanupData();

versus:

migrationSuccessful = CopyData();
if (IsDataCopied())
   migrationSuccessful = CleanupData();

Notice the difference between VerifyCopyData and IsDataCopied. To me IsDataCopied is more meaningful and makes the code flow in a more descriptive pattern.

Thanks for your thoughts!

EDIT: Based on some of the comments, I thought I'd clarify what the IsDataCopied method does. It loops through several directories and files and makes sure the source and destination directory/files match.

Answer 1

I agree with you. To me, IsDataCopied is much more readable.

More generally, VerifyCopyData is, to me, ambiguous as to whether it is strictly a validation method or whether is actually does something. IsDataCopied is very clear that it only checks to see if the data is copied.

Answer 2

"Should" is a broad term. Do what makes sense to you. In a lot of cases, using "Is" clarifies, but not always.

Again, do what makes sense.

Answer 3

It's nice if your methods can contain a verb that helps describe what the method does. VerifyCopyData sounds like it verifies the data, whereas isDataCopied sounds like it tests the existence of the some fact. It's a subtle distinction. Nitpick: I'd call the first method VerifyCopiedData.

Answer 4

I find "Is" to be more clear. A function named "VerifyCopyData()" may throw an exception when the data wasn't copied, or have side effects. Probably not, but if I read it I wouldn't be sure what to expect it to do. A function prefixed with Is is clear: This function will have no side effects and will simply return the boolean answer to the question.

Having an action verb (verify) implies to me that the function actually does something. Using "Is" does not have an action verb, so it implies that the function merely checks the state and doesn't do anything else.

Answer 5

if it would have been any other name i would have given a thought, but VerifyCopyData is definitely less readable than isDataCopied .

Answer 6

I agree. Having the "Is" prefix makes it more clear that this is a boolean function. It's actually a standard in many naming conventions to prefix not only methods but properties and variables.

The Verify prefix isn't as clear since it could very well be a void function or subroutine that does not return anything. For example, Verify could mean that it checks a few things and throws an exception if something is wrong. Where as having the Is prefix implies that you're asking a question and so an answer would be returned.

Answer 7

IsDataCopied is less readable in that the method's intent is unknown. If it simply returns a boolean and does nothing else, then it's fine. But, if it's performing a validation, then there could be a lot of code hidden behind an innocent looking conditional statement.

My advice:

bool isDataProperlyCopied = VerifyCopiedData();
if ( isDataProperlyCopied ) {
   ...
}

Answer 8

I agree with Matthew Jones that is it preferable to name the method IsDataCopied. I would like to add though, that when naming code elements related to other code elements I generally find it better to put the Is inside the the name instead of at the front because it will be closer in Intellisense to the element it is related to (and thus easier to find). For example, in Winforms, Form has a Handle and IsHandleCreated property. If IsHandleCreated was named HandleIsCreated, it would be close to the Handle property and easier to find (not buried way down in Intellisense).

Answer 9

I prefer Is when it comes to variables and properties

if(o.IsDataCopied)
{
}

But in this case with a method call i would opt for something like

if(DataIsCopied())
{
}