Name Things What You Call Them

Similar to how you should PutThingsWhereYouLook for them, in coding you should refactor the name of an item when you accidentally use a different name for it. Say you expect to find WebPage.findLinks(), go ahead and try that. If it turns out that the actual method name is WebPage.getATags(), consider renaming getATags() to findLinks().

I asked in the TestDrivenDevelopment mailing list whether these ideas had already been named and it was recommended that I just add them here. I'm still hoping in the 18,000 other pages around here there's a simpler, shorter version of the same thing, but I can't think what it might be.

This seems maybe a little simplistic. I'm assuming that the driver here is that what one inadvertently calls something can turn out to be a more natural name than what the method was originally named? Is this the basic idea? I guess the problem is what if 5 different people call something by 5 different names? Does that last caller win? Also, has anyone hit that situation where they rename a method something one day, and then realize they like the original name better the next day? Overall, I think this is a neat idea, but one (me included) has to be careful going overboard with "catchy" and "simple" axioms. --RobertDiFalco

The following example was originally at the top of this page

When you mistype the name of a method, say getCharacterHitPoints() and find out it was really supposed to be getCharacterHitpoints(), then you should refactor the name (test first!), not the code you just typed.

In this example the problem is that one day you think hitpoints and the next you think hit points. In the example at the top of the page, you think a tag one day and link the next. Decide on what you really want to call something.

Sometimes the discord is due to one name being internal/implementation (anchor tags) and the other external/client (links). The client code's view should usually prevail. You may need both names, as in the famous:

highlight: aRectangle self invert: aRectangle.

That's not an example of the same concept having more than one name. Highlighting happens to be implemented by inverting a rectangle. If you wanted to change how highlighting was done, you could change this method.

I use this practice for my personal projects; being personal, the issue of somebody else preferring different names doesn't come up. I find that often I think of a more appropriate name once I understand the context I will typically be using a function in; ie, after I've been using it a while. I've renamed lots of things exactly once, but can't think of anything offhand I've renamed twice; so, I'd say this works. -- DanielKnapp

The other day, I came across a set of methods dealing with customizations to objects "under the influence" of other objects. The names used were "from" and "to" objects, respectively. Neither I nor my coworkers could keep them straight, but no one had changed them, for fear of breaking something or offending the original namer. Converting them to "target" and "filter" objects generated many fewer moments of confusion.

I'd say it's actually more important to use in a group than in one's personal code. However, more communication is needed in the group, to make sure the new name makes sense to everyone, and that everyone knows about the change.

An ideal time to do this, IMO, is when you are just fleshing out a new class or method. Names are easiest and least confusing to others to change at this point; try a few out, and RefactorMercilessly until you have something that means what you want. Changing it later will be harder. -- PhilGroce

Using a RefactoringBrowser, you can change names any time you like.

Applied consistently, this practice leads to ScreechinglyObviousCode.

This practice assumes you have a fairly consistent idea of how to choose a better name. It will only really work if you apply it in such a way that your names tend to get better and better. See IntentionRevealingNames.

Wow! How this page has grown. I see a few comments above expressing doubt about the effectiveness or wisdom of this approach in some cases. I think the XP approach addresses most of the issues: go ahead and make the change if you think it's the right thing to do (with your partner's consent!). If somebody else disagrees and plans to change it back, or to another name, it will shortly arise as a topic needing discussion and the team will sort it out in a scrum or something. I just encountered the DeleteOnceRestoreOnce page, which applies to wiki pages but which really applies to this discussion as well, especially in response to the comments by RobertDiFalco above. --PeterHansen

I HaveThisPattern, especially in this variant: Somebody explains some code to me, and says things like "The method getATags is there to find links ", or "The CallableObjectsList? really is an action stack " etc. I try to listen for this, and then suggest renaming these into findLinks, ActionStack? etc. --FalkBruegmann

See: MeaningfulName

CategoryOrganization CategoryNaming