When does it become change for the sake of change?

ctodx
17 March 2009

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 Smile, 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?

33 comment(s)
Rory Becker - DevExpress
Rory Becker - DevExpress

I'd be favour. Piecemeal would also be fine.

17 March, 2009
Daniel Rosenberg
Daniel Rosenberg

Personally, I think it's worth the effort and I think you should do it. I would happily make the resulting changes to our code (and believe me we have a lot of code using DevExpress APIs), simply because it would also make our own code more readable and maintainable.

We already spend a fair deal of time continuously refactoring and cleaning up, changing names to clarify and make things more consistent. This would just be part of that on-going work.

17 March, 2009
Robert Fuchs
Robert Fuchs

> That last one must have been the result of a very long night.

Or from a non-native English speaker - Maybe Oliver? No - Gary ;-)

To get serious: For me it is not worthwhile. I would only do it when I had too much time left. And I never met a developer which had too much time left.

17 March, 2009
Chris Walsh [DX-Squad]
Chris Walsh [DX-Squad]

I am in favor of it, also, you have to remember you also sell your source code, if its not readable to the developer buying it, why would he buy the source code for another one of your products?

I don't find your code bad now, just sometimes hard to follow on those late nights Stick out tongue... Might be time to update the coding standards documentation too to reflect the new changes.

17 March, 2009
Boris Bosnjak
Boris Bosnjak

Today it's a mess of a certain size.  Leaving it so will only create an even bigger mess in the months ahead.  And a year or two from now it'll be such a greater mess that there's no way no how you'd even want or be able to fix it.  

It will forever be a thorn in your side, and more so an embarrassment that you can't rid yourself of.

Bad code must always be fixed, the sooner the better!

Or does one prefer an unfixable, unmitigated and embarrassing mess? :-)

17 March, 2009
Michael Proctor [DX-Squad]
Michael Proctor [DX-Squad]

I too agree, although my applications are small in size and the effects won't be felt much here, I do believe that the easier to read the better.

However I will add this, I must admit I prefer the prefix of Is for a boolean check type field, this allows you to easily identify what fields can provide you with a state (such as NeedsFocus), so in the case of replacing it, there would be no easy way to identify the "state" properties.

Your thoughts?

17 March, 2009
Julian Bucknall (DevExpress)
Julian Bucknall (DevExpress)

Boris: Er, OK, I get the picture Smile...

Michael: I think the slavish adherence to boolean properties starting with "Is" led us to this pretty pass. I think we should break away from this -- before I searched our codebase, I proposed "DoesNeedFocus" as an alternative to my example, which happily also works. I think the stronger imperative in these cases is to select names that are not ambiguous, where nouns can't be misread as verbs and vice versa.

Robert: I would imagine it would get done when the developer was in the code for other reasons. I certainly don't want to stop all development, bring in the Regents of the University of Oxford to vote on our naming conventions, and then change it all. Besides which, we're not talking thousands of properties here, I would guess there are less than a couple of dozen glaring issues.

Cheers, Julian

17 March, 2009
Boris Bosnjak
Boris Bosnjak

If I may add :-)

First, kudos to your developers on raising the issue.  If they're concerned about a small item like naming, you can be sure they'll do a great job on the bigger issues.  A rare find!

As for naming, mucking about with the words in the name may help.  E.g.:

IsNeedFocus -> IsFocusNeeded

IsImageExist -> IsImagePresent (of IsImageAvailable)

IsLargeImageExist -> IsLargeImagePresent

IsExistAnyRowFooterCell -> IsAnyRowFooterCellPresent

I agree with Michael Proctor that the "Is" prefix is a good convention.  However, I note that Microsoft - in their infinite wisdom - foregoes the "Is" in similar situations as those above, for example "System.IO.File.Exists" and "System.IO.Directory.Exists".  These two examples are much more elegant than "IsExists" and therefore justifies the break with convention.

17 March, 2009
Chris Walsh [DX-Squad]
Chris Walsh [DX-Squad]

Boris, you will see the Microsoft in their infinite wisdom, have been listening, the properties on most controls in the silverlight kit use the start "Is" so IsOpen, IsVisible etc.  So its a good path to go down.

17 March, 2009
Luc DEBRUN
Luc DEBRUN

Am sure that while many find this a good idea, some of us would prefer you spent time on those TBDs first. These are the people who buy your products for the wealth of the features and options, not for the code in it.

May be you could limit the code rewrite to the newer products (Silverlight and WPF) which have a smaller code base to update and will have less an impact on your clients since there should be less apps outthere.

Luc

17 March, 2009
Christopher Todd
Christopher Todd

I think it is a great idea; however, I don't have as much time invested in the DX products, so it would be an easy fix for my stuff. I kind of like the Is prefix as long as it makes sense.

17 March, 2009
Michael Proctor [DX-Squad]
Michael Proctor [DX-Squad]

I like Boris suggestion of just "rehashing" the properties to be gramattically correct, and leave the Is prefix.

I will also add things such as a FileInfo class has the IsReadOnly, Array has IsReadOnly, IsFixedSize, IsSyncronized and GDI is full of Is properties. A simple test is to open the View > Object Browser and search the .NET framework for ".Is" and you will see tonnes of properties in this format, as I am sure you would find alot without Is as well :)

I am sure this debate could rage on forever :) and I am happy to leave it in the capable hands of DX cause I know whatever they do it will have good reasoning and help the 'Developer Experience'  :)

17 March, 2009
Hans Nieuwenhuis
Hans Nieuwenhuis

Boris Bosnjak wrote:

"First, kudos to your developers on raising the issue.  If they're concerned about a small item like naming, you can be sure they'll do a great job on the bigger issues.  A rare find!"

Very good remark in my opinion.

I also would rename it. You are developing so many things (my compliments), I think changing those properties is only a small part of all the time you invest. Besides, better named methods/properties will result in people being able to quicker find what they are looking for, which will save time. And it will make them more happy to use your products, which might lead to them promoting your products.

Personally I use 'IsXxx', 'HasXxx' or 'MustXxx' for boolean properties (whichever one is more appropriate).

17 March, 2009
Anonymous
Matt B.

Don't bother.  People can easily deal with small grammatical inconsistencies.  As to the broken windows theory, I would much rather you spent the money on the foundations rather than ornamentation.

17 March, 2009
Julien Ferraro
Julien Ferraro

Hi,

I' definitely think that it's a good idea and that it must be done.

I would go even further and define some naming scheme where possible. After all, in the code, we don't use your products (well, I couldn't live withour CodeRush and Refactor, but that's another story), we use your APIs.

So when renaming these property try to use consistent and easy to find, logical names. You could even rename some method or properties that are grammatically correct but have a better name. Well, I can't think about any of these right now, maybe there aren't any !!!

I like the comment from Hans "I use 'IsXxx', 'HasXxx' or 'MustXxx' for boolean properties", when you're in intellissense and are lookng for a bool property, you know where to search ...

Keep up the excellent work,

Julien

18 March, 2009
Rollie Claro
Rollie Claro

Sounds good. but i am used to the "Is" convention where you expect a property to return "True" or "False"

i dont know how to represent a bool type property without the "Is" prefix

i'd like to leave you with this

"Grammatically Correct" but "Logically wrong"

"Logically Correct" but "Grammatically wrong"

18 March, 2009
Alan Taylor
Alan Taylor

As a heavy user of your products I would tend to agree with Luc. You need to focus on mopping up the TBDs, some of which have been floating around for years, which are much more of a thorn in the side than the gramatical errors.

18 March, 2009
JKDev
JKDev

Yes, I think it is worthwhile. For a start I suggest changing IsNeedFocus to IsFocusNeeded

18 March, 2009
Przemyslaw Wlodarczak
Przemyslaw Wlodarczak

+1 for change.

Your codebase grows rapidly, so does learning curve of your products. I think you are aware that it isn't too flat now. Such refactorings do not provide value in terms of features, but will definitely help to attract new users. Keeping old obsolete code for something like 3, 4 major releases will make changes painless for existing customers. Maybe enhance ProjectConverter to support such changes to make upgrade even easier? Anyway, each step that fight entropy in your code is worth every minute spent.

Personally I would go further. If I were in DevExpress, I'd fight:

* grammatical issues, which is your post about

* consistency issues (example: GridView has EditingValue, whereas PivotGridControl has EditValue. Both serve the same purpose)

* naming condition issues - adopt .Net naming in .Net products line. My favourit example is GridView.BeforeLeaveRow event. I use your grid for 4 years and still look for FocusedRowChanging instead of BeforeLeaveRow.

18 March, 2009
Crono
Crono

Boris makes a good point. However, I believe that "Exists" also is a convention, just like "Is".

Something that is "Present" or not... suggests that the subject does always exists, but may be unavailable at some place or point in time.

Therefore, I too would prefer "Exists" over "Present".

18 March, 2009
Steve Sharkey
Steve Sharkey

Yes I'd say it is worth while - I was delayed earlier when using (incorrectly) the .text property to change text, oops it's the old style .caption

More importantly....

Perhaps you could fix the incorrect spelling of COLOUR ;o)

18 March, 2009
Linton
Linton

I prefer readability over the Is convention. I like the dev's suggestions, e.g. IsLargeImageExist -> LargeImageExists, etc.

I no longer need to know (by its name) that a variable is going to return a TRUE or FALSE: The compiler/intellesense lets me know. But I don't drop 'Is' entirely: The example of IsOpen is good, it reads well and makes logical sense, but IsAnyRowFooterCellPresent seems to be unnecessarily messy when compared to RowFooterCellExists.

Thanks for including users in your deliberation, Julian.

18 March, 2009
Michael Proctor [DX-Squad]
Michael Proctor [DX-Squad]

This would probably be better in the forums would it not Julian? then it would be open to even more discussion and with email alerts :)

18 March, 2009
Jim Clay
Jim Clay

I think it is a good idea as well.  I tend to agree with Boris as well and do like the "Is" prefix.

I think as you say Julian, that it will be done as the devs are in the code for other reasons and not specifically spending their time looking for bad names is a good approach.  I would think that would make everyone happy! :)

18 March, 2009
Adam Leffert
Adam Leffert

I would suggest:

1) Leave the old ones alone.  Spend the time on bug fixes and TBD's.

2) Write a best practices guide telling DX developers how to name things in the future.

18 March, 2009
Minor Bolanos
Minor Bolanos

I agree with Adam Leffert:

1) Leave the old ones alone.  Spend the time on bug fixes and TBD's.

2) Write a best practices guide telling DX developers how to name things in the future.

I add:

3) Spend the time and resources in WPF and Silverlight Component. Remember you are late.

4) I vote to cancel XPO and XFA and move those resources  to WPF and Silverlight Component. Those product do not have any future.

18 March, 2009
Boris Bosnjak
Boris Bosnjak

I cannot believe Minor Bolanos said "I vote to cancel XPO and XFA and move those resources  to WPF and Silverlight Component. Those product do not have any future." :-)

I'm just starting to use them and am thoroughly amazed at how well they work and how quickly I can get a full featured business app up and going with XFA! :-)

What?  My leg being pulled?  Egads...

18 March, 2009
sean kearon
sean kearon

Very worthwhile - making code readable allows readers to understand what it does.  Sensible naming costs very little and helps greatly in achieving that end.

Adding a renamed member equivalent to a badly named existing one, then marking the badly named member obsolete in a subsequent release takes very little from the development effort but adds a lot of polish to the product.

I'm with @Boris - please do do the renames!  I also would take this further and agree strongly with @Przemyslaw and say linguistic consistency across APIs is extremely important and helps build intuition into the product.  The principle of least surprise in any design the "it just works" feeling - and you can't get better than that!

18 March, 2009
Anonymous
Phil Martin

It's an admirable goal, but I would prefer resources to remain in fixing bugs and support.

Maintain a guide and improve the process for new code, and gradually make naming changes as you revisit code.

If you wanted to go back and rename properties, you may as well restructure things. For example, changing the XtraVerticalGrid so it's class structure is closer to that of XtraGrid.

It's a good goal, but I'd prefer an improved set of controls.

Also, for those people who are customers who actively use your source code, it could create major headaches for them as they handle merge conflicts purely because of naming.

18 March, 2009
Anonymous
Brandon Maness

Another thing to consider is getting to the actual usage of the property, so if right now all of your boolean values start with an "Is___" then when I type "this." and type "i" while actually using the object in code, I get a nice grouped together view of all the booleans. Considering that most objects have 20+ properties, I'd say by removing the "Is" you have actually made the object less usable, in a coding sense.

18 March, 2009
Anonymous
Iain Stevenson

Am I being dense here.

The advanced school of busines practice recommends;

Honest mistakes aside, spend the money and time making sure your staff don't screw the pooch in the first place, thus saving everyone the problem and cost of cleaning it up later.

Doh!

20 March, 2009
Karl Rostock_2
Karl Rostock_2

A solid naming convention will in the long run far out way the costs, new users will find it easier to understand when looking through properties as i for 1 get dizzy looking at multiple properties that all start with "Is", but on the other hand can you justify the time and cost involved to your selfs? Its easy for us to say "OH yes that would be great please do" because its not our time or logistical task of organising a potential massive change.

Just my thoughts

20 March, 2009
Anonymous
Harjit Batra

My votes are for:

- Fix it now rather than later

- In favor of the "Is" prefix (consistency, intellisense grouping)

30 March, 2009

Please login or register to post comments.