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?

  • 2
    I don't see anything overly "long" in any of your examples, including closeAndNotify. Commented Dec 6, 2012 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
    Commented Dec 6, 2012 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
    Commented Dec 6, 2012 at 20:14
  • refactoring to a function name with an "and" should be avoided in the first place
    – Ryathal
    Commented Dec 6, 2012 at 20:19
  • 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
    Commented Dec 6, 2012 at 20:35

1 Answer 1


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.