

How is your refactoring done? - makecheck

I've done plenty of refactoring in my code (usually C++), but I'm still hesitant to invest in tools to help.  I limit myself to global "find"; even doing global replacements cautiously, one by one.<p>I think it's because I can't imagine a tool being able to handle all the "quality" aspects of large scale code changes.  For example, a symbol browser might not see #ifdef'd-out blocks; a parser may find references to X in code but not in comments; and aesthetics like proper indentation may be lost.  In other words, if I let a robot "fix" things and move on, I may be burned down the road by confusing code or comments.<p>Are there good refactoring tools that I've just missed?  How do you handle major code changes?
======
brooksbp
Find & Replace...

Eclipse has some nice tools that automate processes like pushing up methods
into superclasses etc... so if you're looking for commercial 'tools', look no
farther than Eclipse.

Still, do not underestimate the power of a sound mind and a good text editor.
Personally, I hate how "refactoring" is being marketed these days; mostly
caused by the managers/business side of software engineering. To me,
refactoring is nothing more than reviewing code, cleaning it up, using better
algorithms, altering for better readability/writability...

"The aim of our studies must be the direction of our mind so that it may form
solid and true judgements on whatever matters arise. We must occupy ourselves
only with those objects that our intellectual powers appear competent to know
certainly and indubitably." Descartes

------
nostrademons

      :%s/find/replace/g
      ./setup.py test
    

I've also got a find/sed script for doing find/replace across a whole
directory tree.

I really do miss having the semantic refactoring tools that are available in
Java IDEs, though. That's one area where I think Java (and Smalltalk) really
leads the pack, and the rest of us are blubbed into accepting half-assed
solutions. Sometime I should check out BicycleRepairMan, but as I understand
it, it's still not as robust as a provably-correct refactoring in a typed
language.

------
cmars232
In Eclipse, mostly with Alt+Shift+R (global rename symbol under cursor). I
don't worry, because xUnit's got my back. I hear your concerns about the
quality. I wouldn't be so bold about refactoring without unit tests to fall
back on.

Btw, for those put off by the term "Test-Driven Development", its really the
"bottom-up programming" you'd do in the more dynamic-languages. That's my take
on it anyway.

------
mullr
I use in-IDE (VS2k5 in my case) refactorings for simple things, mostly in the
small. For local symbol renames and for method extraction, it's invaluable.
Really it's a wrist saver in those cases.

I _occasionally_ do larger level renames using the tool, but I'm always a bit
wary. It's peripheral stuff that I'm worried about, as with you. Any more
major surgery is usually done by hand.

Now, if my tool had better refactorings, I would probably use them.

------
brentr
I personally go through my code by hand using nothing but vim. Consider this
process a means to get to know your source code better.

~~~
qwph
vim's capabilities for search and replace on regular expressions make it
awesome for refactoring. trying to lay your code out as regularly as possible
makes regex refactoring easier, and gives you a nice, consistent codebase as a
bonus.

------
edw519
I never use tools either. By choice. I want to "touch" every line of code as
intimately as possible. I want to immerse myself in it, to feel it, smell it,
touch it, and taste it. I want as much of my code as possible to become part
of my brain's firmware, much like Woz did when he designed the Apple II.

I have a personal rule that no variable name can be completely contained
within another variable name (e.g. $Cust and $CustName must become $CustNbr
and $CustName). This is the perfect application for a tool. Yet I never wrote
it. I WANT to painstakingly walk through every line of code looking for this.
I WANT it to hurt. I want to train my inner hacker to do things right the
first time. What better way than to suffer the consequences?

We train our mind, our bodies, even our spirits. Why not also train our inner
hacker? A few extra minutes per day is well worth it.

~~~
nostrademons
I've found that I rarely know the right name for a variable until I've written
a significant amount of code that depends on that variable. Refactoring's a
must for me, because otherwise what the code says would have little
relationship to what it does. I don't think this is due to a lack of foresight
or planning (I _do_ pencil & paper design notes before I start coding); it's
more that in the process of coding, I discover abstractions and common code
that that aren't apparent until the code's actually written.

