Refactorings

*Refactoring* code is the act (art?) of modifying _how_ code does things, without breaking _what_ it does. Renaming a procedure and then chasing each one of its call sites until it's renamed everywhere is a refactoring. Obviously, such operations are historically so tedious and error-prone in Classic-VB that they are rarely even attempted. Refactoring can be done with more confidence when the code is covered with [unit tests](/Features/UnitTesting). ### [Using Rubberduck refactorings](#using-rubberduck-refactorings) Rubberduck works off its own internal representation of the code that's in the VBE, refactoring actions are unavailable unless there have been no code changes in the project since the last parse. Refactoring actions are sometimes invoked by inspection quick-fixes (in which case their target is automatically set), but most refactorings can also be used directly in the editor _code pane_, by right-clicking (or otherwise selecting) the desired target and picking the appropriate refactoring action from the Rubberduck menu. ### [Undoing refactoring actions](#undoing-refactoring-actions) Because the VBIDE has a very limited _undo stack_, Rubberduck performs all refactoring actions in a module at once, so if 10 or fewer modules are affected by a refactoring, it is possible to fully undo any such refactoring operation. More than that though, and the VBIDE will not be able to track everything that changed. Because it isn't necessarily possible to undo a refactoring, it is recommended to **save your work before proceeding**.