1

Refactoring tools (like ReSharper) often can't be sure whether to rename a given identifier when, for example refactoring a JavaScript function. I guess this is a consequence of JavaScript's dynamic nature.

ReSharper solves this problem by offering to rename reasonable lexical matches too. The developer can opt out of renaming certain functions, if he finds that the lexical match is purely accidental. This means that the developer has to approve every instance that will be affected by the renaming.

For example let's consider we have two Backbone classes which are used completely independently from each other in our application:

var Header = Backbone.View.extend({
    close: function() {...}
})

var Dialog = Backbone.View.extend({
    close: function() {...}
})

If you try to rename Dialog's close method to for example closeAndNotify, then ReSharper will offer to rename all occurences of Header's close method just because they are the same lexically prior to the renaming.

To avoid this problem, please consider this:

var Header = Backbone.View.extend({
    closeHeader: function() {...}
})

var Dialog = Backbone.View.extend({
    closeDialog: function() {...}
})

Now you can rename closeDialog unambiguously - given that you have no other classes having a method with the same name.

Is it worth it to name my functions this way to help future refactoring?

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
Attila Kun
  • 111
  • 3
  • 2
    I don't see anything overly "long" in any of your examples, including `closeAndNotify`. – Robert Harvey Dec 06 '12 at 20:05
  • Keep in mind that Resharper does not always suggest the ideal setup, sometimes its choices are not ideal, that is why they provided as choices. However I think the bigger question is, do you want `close` to mean something different? – Guvante Dec 06 '12 at 20:09
  • @Robert Harvey: You are right, the function names in my examples are not long at all. I've tried to make my issue clear in my edit. – Attila Kun Dec 06 '12 at 20:14
  • refactoring to a function name with an "and" should be avoided in the first place – Ryathal Dec 06 '12 at 20:19
  • Resharper doesn't seem very smart here. Visual Studio only renames identifiers that are actually *referenced* to the original identifier being renamed. If your tool is forcing you into an inconvenient naming practice, I would suggest that it is the tool's failing, not your practices. – Robert Harvey Dec 06 '12 at 20:19
  • @Ryathal: That sort of sweeping generalization seems unjustified. – Robert Harvey Dec 06 '12 at 20:20
  • 1
    @RobertHarvey using and in a function name is admitting to failing the SRP, I don't see how breaking the srp would be an improvement – Ryathal Dec 06 '12 at 20:35
  • @Ryathal: I don't agree that using `and` in a function name is an admission of an SRP violation. It's these kinds of pedantic distinctions that can so often make life difficult for programmers. There are only two absolutes in programming: fulfill the requirements, and fulfill the requirements. If principles and standards can help achieve those absolutes, great. If they become an impediment... – Robert Harvey Dec 06 '12 at 20:40
  • @RobertHarvey I agree with you when developing, but this is about refactoring. The requirements were already meant, why are you changing working code if not to better align with standards – Ryathal Dec 06 '12 at 21:10

1 Answers1

2

Is it justified to use overly long function or variable names to help future refactoring?

"overly long" implies that the names are too long, but the situation you describe makes me think that part of the problem is that names like close are not long enough, or more properly, specific enough. Long names are helpful not just to automated tools, but to the humans that have to work with them. I'd suggest choosing names that are informative.

It is, of course, possible to go too far. If you insist on every name being unique across the entire project you'll create a headache for yourself just in terms of trying to manage all those names. I'd suggest using names that are sufficiently descriptive that you can easily understand them. You may still have to review changes by hand sometimes, but if the name in question is descriptive you won't have trouble deciding whether or not a change is appropriate.

Caleb
  • 38,959
  • 8
  • 94
  • 152