Posts Tagged refactoring
During the year that I was on a Java project, I found Eclipse’s automated refactoring tools such a productivity boost. I remember doing probably my first automated Extract Method and seeing it automatically deduce which parameters would need to be passed, and saying “No way. No way!” And then you could rename methods (and it would update the dependencies); you could extract a local variable; you could do a quick fix… I would find myself giggling and sometimes laughing out loud – there were all these mundane, tedious and error-prone manual manipulations of source code that I was used to doing, being careful and manually checking everywhere to try not to miss something – and now that I could use the Refactor menu my mind was freed to think about the problem I needed to solve. Wow!
Automated refactoring was such a productivity and energy boost. I don’t want to go back to the way it was before. So, now that I’m in C++, I’m interested in finding an automated refactoring tool for C++ – preferably one that integrates with Visual Studio.
What’s Out There?
For C++ development, a quick Google search turned up devexpress‘s Refactor! for C++ and Whole Tomato Software‘s Visual Assist product, both of which integrate with Microsoft Visual Studio. Refactor! for C++ is a free download, whereas Visual Assist costs $249 with $49 maintenance renewals (or $99 for a license that is not eligible for the renewals).
For Tonight’s Program, the Screenshots Part Will Be Played By…
Here is the part where I would take a bunch of screen shots demonstrating the use of Extract Method… but Whole Tomato has a nice post about that on codeproject already. Helpful to see the tool in action.
Out With a Whimper
And to add to the letdown of me not having my own screenshots… I haven’t come to a conclusion yet either. I have SlickEdit, the trial version of Visual Assist X, and Refactor! for C++ installed. Guess we’ll try ’em and see!
Refactoring Tools Shoot Out by Legalize Adulthood
All developers are equal, but some are more equal… (Maciek Talaska)
SlickEdit – Programmer’s Editor (cplus.about.com)
There is a refactoring I do in Eclipse sometimes that confuses Subversion:
Suppose I have a class named MessageSender. It does not implement an interface; it just does the work itself. Now perhaps I want a MessageSender to be an interface and have a MessageSenderImpl. To accomplish this change, I:
- Rename MessageSender to MessageSenderImpl.
- Extract Interface on MessageSenderImpl and call it MessageSender.
At this point, I can see that Subversion is confused, because there is a little red X in the icon for MessageSender.java in the Package Explorer:
If I commit my changes now, MessageSender.java will be deleted and the build will be broken if I have any code using the new interface.
My current workaround is to:
- Revert MessageSender.java, then
- Replace With Previous from Local History
But this is more work than it oughter be, ain’t so?
Update 10/13/2008: Karl’s comment inspired me to post my question to the Subclipse email list, where Mark Phippard told me that an enhancement to Subclipse released in Subclipse 1.4.3 fixes this issue. (I was using Subclipse 1.4.2). I upgraded Subclipse to the current version (1.4.5) and now my two-step refactoring works (i.e., after step 2 the file is marked as changed rather than marked for deletion, so I don’t have to do my workaround).
Thanks, Karl and Mark!