Eclipse: Most useful refactorings [closed]
Every now and again, I make use of the Eclipse refactoring feature. Some techniques are more obvious then others and some I never tried.
What refactoring is most useful for you and why?
Note: I find this presentation very useful, perhaps because it is example driven therefore easy to understand:
"Refactoring for everyone - How and why to use Eclipse's automated refactoring fea开发者_StackOverflowtures"
Edit: This article is useful as well (Thanks jitter)
Explore refactoring functions in Eclipse JDT
It is an interesting question. I know what works for me and it is interesting to see what others use.
I decided to take a more scientific approach to determine the most commonly used refactoring commands. Eclipse has a Usage Data Collector (UDC) feature built in. The data is publicly available. I took the data and extracted the following graph which shows the most commonly used editing commands (without navigation commands).
alt text http://img.skitch.com/20091207-bmcng36rjy837sqmcx58b85age.gif
However, I am a strong believer in "Save Actions" for formatting and organizing imports (read my article about it), so I wouldn't count those. I would also remove the commenting actions. The picture looks like this: alt text http://img.skitch.com/20091207-ieas1mk5114fwitucqkqxyw6t.gif
Rename - because giving things meaningful names is the best way to write self-documenting code. Shift+Alt+R
Extract method - whenever a method gets too long. Shift+Alt+M
Extract constant - because magic numbers are bad. Shift+Alt+T (refactoring menu, there's no direct shortcut).
Inline/introduce variable - to remove clutter from methods. Shift+Alt+I (inline), Shift+Alt+L (introduce)
My favourites (in order of using):
- Rename (
Alt-Shift-R
, orCtrl-1
for faster in-file renaming)
Good renaming variables,methods,etc. without side effects. - Extract Variable (
Ctrl-1
,Alt-Shift-L
)
Good for splitting a quick-made-100-character-line to separate steps. - Extract Method (
Alt-Shift-M
)
Create a method out of some code without any side effects. - Split Variable Declaration (
Ctrl-1
)
Good when you initialize a variable at the declaration and now find out, that the initialisation needs to be in a try- or if-block. - Change Method Signature (
Alt-Shift-C
)
The handy Swiss Army Knife of method signature manipulation, including default values for new parameters. - Pull Up/Push Down Pull methods and variables to a generic interface or superclass or push it down to a subclass
- Extract Interface/Superclass
Extract an interface or a superclass out of the current class. Very handy.
My favorites:
- Renaming
- Pull up/Push Down
- Extract Method
The most popular refactorings have been stated, and I entirely agree with them.
Code formatter (Source, Format or Ctrl Shift F) is one of the features of the IDE I use very often. True, it is not refactoring, but it improves code readability while maintaining your coding style: simply head to Preferences, Java, Code Style, Formatter and tell Eclipse how you want your code to look!
Generate Getters and Setters is also a feature I find to save time when writing Java beans.
Eclipse has perhaps the least refactorings for all the popular IDEs. You might consider Netbeans or IntelliJ (Community edition is free). Conversely Eclipse has possibly the best debugger. ;)
I use refactoring as I write the code (which I have found speeds up writing by about 15%) so IntelliJ's ability to refactor code which does not compile very useful for me. The other IDEs may support this now (does any one know?) I find IntelliJ's smart complete is a fair bit smarter as well.
I have tested retyping a files from printout (originally written in eclipse) and found I used 30% less keys and 50% less mouse movements when typing the file with IntelliJ (compared with Eclipse) I would estimate Netbeans to be somewhere in the middle.
My favorites are:
1) Rename - It works on method names, variable names, class names, fields-- really anything with a name.
2) Convert Anonymous Class to Nested - Helps with debugging, lets you reuse logic (such as a comparator) that you only thought that you'd use in one place.
3) Convert Member Type to Top Level - Frequently after making an anonymous class into a nested class I discover that the class is useful elsewhere. This refactoring is perfect then.
What I use the most is Rename, Extract Method and Change Method Signature, in that order.
CTRL + 1 on a red lined section, i.e. quick fix.
I like the Extract Method (Alt+Shift+M), and since 3.6M1, it now handles selections that contain continue statements.
To preserve the semantics of the existing code, the selection needs to include the last statement of the loop. In the extracted method, continue statements are changed to return:
Extract method refactoring with continue http://download.eclipse.org/eclipse/downloads/drops/S-3.6M1-200908061400/images/extract-method-continue.png
For a selection that would need multiple return values in the extracted method, Eclipse now lists the conflicting variables in the error message:
Extract method refactoring with an ambiguous return value error http://download.eclipse.org/eclipse/downloads/drops/S-3.6M1-200908061400/images/extract-method-multiple-return-values.png
I use :
1- Rename - to correct better method name
2- Move - to organize my package in better ways, like when I start my project, it was so small so no need of a io package, but now yes.
3- Generate Comments -when I create a .class avoid me to re-copy the GPL license, etc
4- Correct Indentation - to keep my code readable.
It's also worth reading this research: How do API evolve? A story of refactoring. by D. Dig and R. Johnson.
The authors noticed that 80% of the changes were refactorings and classified them. Here is the abstract:
Frameworks and libraries change their APIs. Migrating an application to the new API is tedious and disrupts the development process. Although some tools and ideas have been proposed to solve the evolution of APIs, most updates are done manually. To better understand the requirements for migration tools, we studied the API changes of four frameworks and one library. We discovered that the changes that break existing applications are not random, but tend to fall into particular categories. Over 80% of these changes are refactorings. This suggests that refactoring-based migration tools should be used to update applications.
"It's also worth reading this research: How do API evolve? A story of refactoring. by D. Dig and R. Johnson.
The authors noticed that 80% of the changes were refactorings and classified them. Here is the abstract ... "
80% of the BREAKING changes were observed to be refactorings. The refactorings themselves formed only 20 - 30% of the API changes..
精彩评论