336 - Refactoring-Top-Seven-(My-Personal)

It isn’t too much of an understatement to say that Eclipse’s refactoring capabilities have changed the way I code. Not by much, but a little. Mainly it’s little things; I have certain things I do now with regularity that I’d have be worried about doing before. Anyway, here goes:

1. Renaming variables/methods/classes/etc. I use this too often to mention. Find you’re doing something with a variable you didn’t think about before and its name isn’t too helpful anymore? Alt-Shift-R it! Makes my code that bit more readable. Of course, all references to the item in your source tree is changed, a major time-saver.
   
2. Breaking out methods. Yeah, so I know you’re meant to have things in small methods, but sometimes it seems that code just comes in long splurging methods. Don’t worry! Break it out into a method with the refactoring tools ‘cause they’ll figure out what you need to pass and return. Seems pretty clever in that Eclipse will find where you’ve used the same code path in other places in the class and change them into calls to the new method.
   
3. Inlining methods. Find you didn’t need to break out that method in the end? Too much of a bind to put it back again? Refactor->Inline code to the rescue!
   
4. Moving methods around. Strictly, this isn’t refactoring, but I’m going to put it here anyway. Dragging and dropping methods around your source outline is pretty useful, especially to put all the methods you’re working on in one place for a while.
   
5. Moving variables to fields. Sometimes it’d just be useful to have global access to a variable, but you’ve got it stuck in a method somewhere. No problem, click it and send it to field status. This helps cause you don’t have to bother working out where the variable was declared. Note that this isn’t perfect yet, e.g. Eclipse doesn’t remove places where you’ve passed the variable as a parameter.
   
6. Taking long statements that you’ve passed as a parameter and making a local variable out of them. Also changes other places where you’ve used the crazy long sequence of method().method().method()… Generally most helpful in debugging, though sometimes a well named variable does wonders for readability of your code.
   
7. Moving things around. You can also move entire classes and packages and have the rest of the project update. Maybe not so good for CVS because you’ll lose your history for the file; useful as hell, however, at the beginning of a project where you want the code to be more malleable.
   

So, I originally planned for ten items, but these are the only ones I could remember without opening Eclipse up to see what I tended to use. Still, a pretty useful list of things you can do, in my opinion. Bring on hardcore refactoring, I say, what we’ve seen so far has just touched the surface!