Localize Module Variables: This refactoring analyzes the way that private module-level variables are referenced,determines the optimum scope of each private module-level variable based on its usage within the module, and lets you customize and execute any/all the variable moves with great ease.
Localize Module Variable Example
Localize Module Variables is not an officially-catalogued refactoring, so far as this author knows, but it meets the definition of a refactoring: it should not change the behavior of your code. Here's how it works:
| 1. | CodeShine scans the module, and for each private, module-level variable, it determines which routines reference the variable. |
| 2. | CodeShine makes a suggestion based on the number of routines that reference each variable. |
| • | if no routines reference the variable, CodeShine suggests that you delete it. |
| • | if exactly one routine references the variable, then CodeShine suggests that you move the variable into that routine, to improve encapsulation and clarity |
| • | if multiple routines reference the variable, then CodeShine suggests that you leave it alone |
| 3. | All of CodeShine's suggestions will be logically correct, in that clicking Execute will result in code that will compile and behave as before; however, some of them may not correspond with your intentions for the future usage of these variables (CodeShine will suggest that you delete an unreferenced variable, for instance, while you might know that you're just about to write code that will reference that variable). Because of this, you have the opportunity to change/disable each action individually, and it is not recommended that you click Execute without due consideration of each variable to be moved or deleted (although, as usual, Undo will allow you to back out the operation if you change your mind). |
Additional "counter-example": if you are using a module-level variable as a "static" variable that is only referenced by one procedure, then CodeShine will recommend moving it to that procedure, which would probably not correspond with your intentions (TODO: click here for details and description of problems with VB Statics). For this reason, we recommend naming these variables in a way that indicates their function; e.g., m_stSuspendUpdates.
With those cavaets in mind, this is a great tool for simplifying the structure of a module, especially if "the last programmer" wasn't too careful about encapsulation. It is also can be useful after you've made significant changes to a module - if you've deleted or consolidated several routines, for instance, you may now have one or more module-level variables that can be "localized."
If all of the suggested Actions are None, then that's an indication that all private module-level variables appear to be appropriately scoped; however, (as explained above), suggested Actions other than None are not necesarily indications of problems; they are simply indicate which variables to consider moving or deleting.