Illusory Follies

Some in computer programming have insisted on using the prefix is for all boolean data types. I’ve been bumping against this lately. I think it’s silly. It’s a form of Hungarian notation which seems unnecessary considering that the compiler/interpreter in almost all cases will help us deal with type issues. For readabilities’ sake, wouldn’t it make sense to name something what it represents? For example, if the boolean variable represents the state of being done, I suppose isDone may be an OK name. But if it represents the state of something that may or may not have been done 3 years ago, a better name might be wasDone. What if we want special checking to take place if a flag is set? Should that flag be called isCheck? It seems silly — maybe shouldCheck would work. What if we’re talking about ownership or class relationship. isChild works as a name to indicate class relation, but hasChildren is a perfectly logical name to define the inverse relationship. I saw a few places that advocate the use of helping verbs (have, has, had, do, does, did, shall, should, will, would, may, might, can, could, and must) or verbs of being (am, is, are, was, were, be, being, and been) to prefix these names. This makes sense. However, we speak English and sometimes in English we drop helping verbs (think of did for example). Is something.didSucceed better or worse than something.succeeded? There are numerous similar examples.

I think in the end, naming variables to make them readable is much more important than following some convention. Or perhaps I should rephrase that: the convention we ought to follow is the convention of written English, not some tightly defined arbitrary subset.