Prefix "Is" in Method Name for Verification Methods

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.

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.

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).

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.

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 ) {
   ...
}

It's definitely subjective, and, at different times (working with different libraries and even different languages), I've both always used such prefixes and never used them—mixing this convention with not using it would often be a mistake. Decide which is clearest based on the context, including what is already being done in that project/library/etc.

For example, obj.DataIsCopied() flows better to a native English speaker, but then you have !obj.DataIsCopied() (or not). You have to face that you're writing code and need conventions, and those conventions add meaning (in the descriptive sense) subjectively.

Additionally, I'd expect any method named Verify to do some "real" work to verify, while Is should either return an pre-computed/already-available value or compute it trivially. In languages where you have properties this is much easier to express, as you can separate things that are "actions" from those that are not. E.g. using if (obj.data_copied), whether that is a data member or a trivial function, like IsDataCopied would be, is encapsulated.

data.isCopied()

Because English is not VSO, but SVO.

"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.

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.

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

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.

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())
{
}