When does it become change for the sake of change?

So I got an email from R&D the other day:

The guys are asking if they should go through property lists and rename properties with bad grammar:

• IsNeedFocus
• IsImageExist
• etc

These won’t be breaking changes – they’ll create new properly-named properties and mark the old ones as obsolete.

I'm not quite sure what prompted this particular project — developers can be quite ungrammatical at times and often these slips are never caught before a product is released and it's all set in stone. I replied:

Well, in theory it's fine (that is, create new identifier, mark old one as obsolete), but let's take a look at the list of old names and new names that they have.

And I got this nascent list this morning:

• IsNeedFocus -> NeedsFocus
• IsImageExist -> ImageExists
• IsLargeImageExist -> LargeImageExists
• IsExistAnyRowFooterCell -> ?
• etc

Now, I'll be the first to admit that the original names won't win any linguistic prizes; in fact, they make code jarring to read. (That last one must have been the result of a very long night.) For example, here's the first one of those instances being used in our code (and in fact it's the only time it's used):

edit.Visible = true;
if(checkForFocus) {
  if(edit.IsNeedFocus) edit.Focus();
} else 
  edit.Focus();

Here edit is an editor control. Now, to me, that nested if is very hard to read as it stands: "if edit is need focus then edit-focus". The suggested change would make it:

edit.Visible = true;
if(checkForFocus) {
  if(edit.NeedsFocus) edit.Focus();
} else 
  edit.Focus();

Which I'm sure you will agree is much more readable: "if edit needs focus then edit-focus".

Now, the thing is, I'm undecided on how to proceed with this project. To me, this is a strong example of the "broken window" theory, that a small defect, left untended and unrepaired, leads users to believe that we don't care about our code so why should they; that if we can't even be bothered to fix a glaring easy-to-solve issue, albeit small, then the rest of our code becomes suspect.

However, changing these names is not free. First of all, R&D has to determine which names are valid for change and which can be left alone. They have to write the new properties (and methods), and then mark the old ones as obsolete (the Refactor! Pro Safe Rename refactoring would come in handy here, obviously). They then have to recompile everything (demos and all) and fix all the warnings about obsolete usages. The tech writers have to come in on the act, and make sure the documentation is changed to reflect the new names (and that includes the embedded examples). The support team have to check the knowledgebase and so on. And that's just our costs. Your costs, we'll blithely ignore , but of course these changes will have an effect on your code too and you'll have to make modifications and retest.

So my question to you is, is this worthwhile? Does our laudable goal of improving our clumsy use of English (repairing the broken window) make sense? Do you care enough to have to change your code? What if we did it piecemeal, a product a release, say?

Free DevExpress Products - Get Your Copy Today