| Author |
 Topic  |
|
|
mmb
Senior Member
42 Posts |
 Posted - Jun 27 2006 : 05:44:44 AM
|
While extracting a method is a nice tool, I often need a much simpler one: extracting a local variable:
func1(bla(34), 7);
...
func2(4, bla(34));
should be transformed into
type myvar = bla(34);
func1(myvar, 7);
...
func2(4, myvar);
The new variable declaration should be placed at the beginning of the current function/method as the best place is not easy to determine without dominator ...
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Jun 27 2006 : 4:29:50 PM
|
i wonder if this is going to lead to a pile of new feature requests 
still it is an interesting idea, so i have put in a feature request.
case=1492 |
zen is the art of being at one with the two'ness |
 |
|
|
support
Whole Tomato Software
5566 Posts |
|
|
Queequeg
Senior Member
Germany
36 Posts |
Posted - Mar 16 2011 : 3:29:57 PM
|
First I would like to know if there's something like a bug/feature tracker somewhere. You put these IDs like 'case=1492' in these threads, so I'm guessing there is. Is it possible to vote on which request I'd like to see implemented the most? Maybe this could be addressed in a sticky thread in this subforum.
Second, I'd like to to bump this request. It's the one refactoring I use the second most (after rename) in Eclipse JDT, and it's dearly missed since I switched to C++/VS. The good thing about this refactoring: It promotes a style where local variable names are a form of documentation. More importantly, you don't have to type the type of the variable anymore. Not having to type something like std::pair<ISausage, boost::shared_ptr<ITopping>> is a huge win in my book.
To implement this refactoring it's necessary to determine the type of an expression, which might be complicated in general. However, Visual Assist is able to determine the return value of functions/methods. So it should be relatively easy to implement transformations like this:
bool doStuff();
if(doStuff(value))
{
return doStuff(value);
} into bool doStuff();
bool stuff = doStuff(value);
if(stuff)
{
return stuff;
}
If you put the cursor over one of the calls to test(), the signature of the function is displayed in the VA navigation bar, so the return value is know to VAX.
VAX is not always able to choose the correct overload though. Consinder the following code:
bool test();
std::string test(int);
test();
In this case, if you put the cursor on the call to test(), the navigation bar displays the wrong signature first, std::string test(int). If you switch the declarations, it displays the other overload. It would be nice if it would at least take the number of arguments into account (bonus points for considering default arguments).
Anyways, if the type of the expression could not be determined reliably, the automatic refactoring could simply use auto. It might not (yet) work everywhere, but the worst that can happen is that the user has to type the type of the variable. Which she would have to do anyways when refactoring manually, so it's not more work.
I think even if a first implementation of this refactoring would only support expressions that look like method/function calls, it would be very useful, since this is definetely the most common use case. Constants might be useful too, but less important. Operators are certainly more complicated, and if people choose to do weird stuff like class A { B operator ++(); };, who cares anyways. :)
BTW, in Eclipse, this refactoring is implemented such that the declaration and initialization of the variable is inserted, and every occurrence of the expression is replaced. It chooses quite sensible defaults for the variable name, e.g. a call to getResourceAllocator() results in a variable called resourceAllocator (recognizes get*, has*, use*). The variable name is then selected, and by simply typing in the editor, the user can change the name of the variable, which replaces the name in every occurrence. It's like a real-time Refactor->Rename, but easier to implement since it's only a local variable. The good thing about this feature is that it's not necessary to display a dialog. |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Mar 16 2011 : 11:58:30 PM
|
We are still looking to add this refactoring command at some point, but I don't currently have an estimate for when.
Figuring out which function overload is being called is something we are aware of, but as you realise, this can be a hard problem in C++ unless you are actually the compiler, and know all about all of the code.
Having this command default to "auto" when it doubt is a very interesting, and sensible idea. This won't help with older IDE's where the compiler does not support this new keyword, but it is a useful place holder all the same. I have put a note onto the case about this.
The way you describe Eclipse renaming variables when you edit is interesting, but it sounds like it could cause problems if you were trying to edit, but not rename. VA does have a similar feature, but it has to be triggered, it is not automatic. See the "Rename after Change to Definition" section here:
http://www.wholetomato.com/products/features/rename.asp
VA will offer rename with or without a preview if it decides you are renaming a symbol in your code. |
zen is the art of being at one with the two'ness |
|
|
|
mnieber
New Member
6 Posts |
Posted - Jun 02 2014 : 03:06:29 AM
|
| Same as Queequeg, this would be my 2nd most used feature, if it were there! |
|
|
|
feline
Whole Tomato Software
United Kingdom
19020 Posts |
Posted - Jun 02 2014 : 10:18:44 PM
|
| This is useful to know, thank you, knowing what is most interesting and popular helps us to prioritise planned features and bug fixes correctly. |
zen is the art of being at one with the two'ness |
|
|
|
sean
Whole Tomato Software
USA
2817 Posts |
Posted - Nov 07 2014 : 10:07:20 AM
|
| case=1492 is implemented in build 2052 |
|
|
| |
Topic |
|
|
|
Refactoring: Extract Local Variable
