How is your refactoring done? | Hacker News Reader

How is your refactoring done?

5 pointsmakecheck8 comments

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.

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.

Are there good refactoring tools that I've just missed? How do you handle major code changes?

View on HN

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

  :%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.

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com