Let's start by talking about Rename.  I view Rename as being one of the “Tier 1” refactorings – the refactoring we absolutely must provide, and which must be of the highest quality.  They must be fast, reliable, and easy to use.  You’re going to use them often, and we want you to like them a lot.

What does it look like?

1. Place the cursor on a name
2. Right click, select Refactor->Rename
   > Prompt appears for the new name.
3. Type new Name
4. Hit OK
   > All uses (“references”) of that entity get updated to the new name.

There’s also an option to see a preview of the changes before they get applied.  I think you’ll use the preview the first time, and then turn if off.  You don’t need it when the refactoring tool is reliable; you’ve got more important things to do.

What kinds of things can you rename?

Just about anything.  The UI is pretty much the same for namespaces, types, fields, locals/args, and methods.  For methods we will offer to rename overloads as well.

Will you fix up comments, too?

I argued that we should not support fixing up comments.  Our refactorings are designed to be reliable – you can know that when you use them, the result will be what you expect.  But we can’t really do comment fixup reliably, since it’s prose, not C# -- the semantics aren’t well defined.

Consider:

Go to the marked line & rename ‘i'.  If you ask us to update comments, we’ll change the one on the field, as well.  That’s probably not what you wanted, but there’s no way for us to know that.

In my not-at-all-humble opinion, if you want to update comments, you should use Find & Replace in Files, instead of the Rename Refactoring.  Find/Replace is not very smart, but you expect that, and you already know how to manage it to get the result you want.

However, every time we showed people Rename, their first question was “Will you fix up comments, too?”  So, we are including an option to fix up strings.

Can I toggle off specific changes in the Preview?

Normally, no. 

If you’re a Refactoring purist, I’ll tell you that we applied the definition of Refactoring (specifically, the “leaves its behavior unchanged” part).  If you could toggle off a specific reference, the behavior would change.  (Specifically, your code would go from legal to C# to not legal C#.)

If you’re a Refactoring pragmatist, I’ll tell you that Find & Replace in Files has appropriate user interaction model for this kind of activity. 

If you elect to Search in Comments, then you get some checkboxes for the comments. 

Can I rename across projects?

Yes, but only if they’re C# projects.  If you have VB and C# projects in the same solution, the VB references won’t be updated.

We have some smarts about renaming between the forms designer, the editor, and the solution explorer.  For example, if you follow 1-class-per-file, and you rename a file, it’ll rename the class, too.

What are the hard parts of implementing Rename?

• Find the right definition.  If you rename from a reference, we gotta figure out which something you want to rename.
  
  
• Find the right references.  We need to look in opened & closed files, this project & other projects, etc.
  
  
• Don’t break your code.  There are situations where are rename will change the semantics of your code, but leave it legal.  We need to be careful to detect these situations.
  
  
• Dealing with illegal code.  Actually, this issue spans all refactorings.  Purists don’t care, because they don’t refactor unbuildable code.  They built & ran their NUnit tests 30 seconds ago, and they’re about to do it again.  But if you don’t work that way, you probably expect Rename to work while your code is still “in progress”.

Your feedback.

Reading this blog, do you think we’re making the right choices in our Rename design? 

Are we providing the functionality you expect?

Are there parts of this feature description that look like a waste of our efforts?

When commenting, say where you put yourself on the “Refactoring Purist” scale.