| T O P I C R E V I E W |
| legalize |
Posted - Mar 27 2013 : 2:22:47 PM
Summary: When an identifiers is declared in a single statement, move the declaration to immediately before the first scope that uses the variable.
Example:
Source code reads: int i = 0;
// other lines of code that don't use i
std::cout << i; and the cursor is anywhere between the type and the semi-colon and I select "Localize Variable", the code becomes // other lines of code that don't use i;
int i = 0;
std::cout << i;
Rationale:
A common refactoring activity is to perform "Compose Method"[1] on long methods and functions.
Long methods often have lots of local state that is stored in variables defined in the local scope. Often times, the declarations are grouped together at the top of a large scope, which may be the beginning of the method or the beginning of a large block.
When performing Compose Method, these variables are going to end up as local variables in the extracted submethods, but first we need to localize their use or Extract Method will consider them modifiable parameters of the original scope that need to be passed in and out of the extracted methods.
So, before we can get VAX's Extract Method to do something useful for us (remember, we want to use automated tools to change the code in order to avoid the mistakes that come from making manual changes to code), we need to localize the variables used in each block we intend to extract.
Some cases to consider:
- The variable may be used in more than one location and the declaration should be moved to the common enclosing scope of all uses within the method. For instance, if the variable foo is declared at the top of a method and used in both the 'then' and 'else' branches of an if statement, it would be an error to localize the declaration to the block of the 'then' statement as the 'else' block would no longer have access to the variable.
- The initialization expression of the variable, if present, may cause other dependencies that prevent or constrain the declaration from being moved.
Even in a limited form of this refactoring that wasn't available when analysis was difficult would be useful. Dependency analysis and parsing can make this hard for the fully general case, so something that handled the simple cases first would still be useful.
[1] "Compose Method" refactoring:
http://www.industriallogic.com/xp/refactoring/composeMethod.html
See "Refactoring to Patterns", by Joshua Kerievsky.
|
| 3 L A T E S T R E P L I E S (Newest First) |
| feline |
Posted - Mar 29 2013 : 3:16:28 PM
There are some known problems with Extract Method, not to many, but a few. All of the problems that have been reported have been logged, and are on our list of bugs to fix, its just a matter of working out where you focus your resorces. Generally Extract Method works well enough, but its not perfect 
This is our focus, a set of fairly small and well defined refactoring commands that don't try to do to much, and that can be chained together to produce the desired end result. Some of the code I see reported though, it makes this an interesting challenge |
| legalize |
Posted - Mar 28 2013 : 11:31:06 AM
Yes, that would be a good enhancement to Extract Method. If I had Localize Variable, then the existing implementation of Extract Method would get this right a lot more often :).
Extract Method is very useful, but I've noticed certain code aspects give it a hard time and cause it to introduce unwanted parameters into the extracted method. Localize Variable is something that I often do first by hand in order for Extract Method to work better.
My general approach to these selections is for VAX to include more "micro refactorings". Very, very small, steps that are useful to automate. As a developer I can then apply a bunch of high quality micro refactoring steps in order to achieve a larger refactoring without making any changes by hand. The more I can automate the refactorings in a reliable manner, the more refactorign I can do with confidence that I didn't break anything.
This means, in general, that we should be striving for highly reliable small step additions to VAX before we start tackling the larger refactoring problems. For the tool developer, it also means that the larger refactorings can be composed from a series of micro refactorings applied in a standard sequence. |
| feline |
Posted - Mar 27 2013 : 3:07:11 PM
I like this idea, and you make a very good case for it. One of the features we are considering adding to VA is that when you use Extract Method, if a local variable is only used inside the selected code, Extract Method should also grab the variables declaration when doing the extract, even if the declaration has not been selected:
case=63055
So I am wondering if you see this being useful mainly for Extract Method, or if it is generally useful by its self? This is going to come down to personal preference and coding standards really I suspect. Personally I tend to place "important" local variables at the start of a function, for easy reference, and declare loop counters where I use them. |
|
|
