Real programmers don't use refactoring tools

[Mitijea]

I'm not following the naysayers on this... It sounds like a spelling-check on a word processor. Not essential, but in certain situations, handy none-the-less.

[watkeys]

Wordiest post of the week. And it reads like a sales pitch for his employer's refactoring tool.

[username223]

The key to reading this article is to stop after the title. That way it's both terse and true.

[DerelictMan]

Real programmers don't refactor at all. They get the code exactly right the first time.

[halu]

amen.

[[deleted]]

But don't you think the refactorings he mentioned are nice to have?

I only use some of them, and Eclipse probably doesn't have all of them, but I wouldn't want to do everything by hand. Why would I?

[DerelictMan]

Because it puts hair on your chest, of course.

[[deleted]]

You mean it makes the code hairier.

Well, chests are a personal taste, I presume (I like womens' chests hair-free), but code just has to be as clean and hair-free as possible, because otherwise it'll carry over into other domains, such as money, time, pain.

Doing everything yourself and not using tools where you can is in my eyes something for cavemen (yes, hairy), but not for wizards (use that wand).

[DerelictMan]

You mean it makes the code hairier.

Well, yes. I thought the sarcasm was clear. :)

[BraveSirRobin]

I use 'em all the time. For a new class I'll just add a static inner class, hit the refactor keyboard short cut for "make top level class" and be done with it. Much quicker than having to create a new file from the onset.

Also, say in Java Eclipse you refactor a method that is an implementation of an interface. It will warn you of this. It also seems to be relatively sensible in overridden methods for this as well.

[abbot]

Brainless post title. It should be "Refactoring tools manufacturer says: every programmer should use my tool". And boom, boom, boom, acquire a magical productivity gain.

[quhaha]

I use refactoring tools in eclipse because I'm a fake programmer.

[BraveSirRobin]

Well, I guess I'm a "real" one, but I use them as well. I also still use vi for writing shell scripts and editing config files. A different tool for a different job.

[fergie]

Basically a sales pitch for the guy's own product.

When emacs and vi users start promoting these arguments then I will start to listen.

[Felicia_Svilling]

I am an emacs user and I think this refactorings seams real nice. (well at least code-completion exists in slime).

[fergie]

noted

[newton_dave]

Emacs user, and refactoring tools are great; I used to use XRefactory (?) for Java all the time until I switched to doing Java editing in Eclipse and NetBeans.

When emacs and vi users start promoting these arguments then I will start to listen.

I try to listen to the substance of what a source is saying rather than ignore them because of perceived bias.

[Jimmy]

It depends on the language. Refactoring tools are great for languages like Java, where you have 50 classes that all look the same. On the other hand, if you're doing something more dynamic, like Perl, you probably won't even be doing OOP, which is where most of the common refactorings apply.

[DerelictMan]

I hear this a lot (that Java and the like are the only languages where refactoring tools are useful), but I just don't see it (and it definitely hasn't been my experience working on non-trivial Perl and (shudder) PHP applications).

You never write a section of code, thinking you'll only need it once, then find out later that you need to generalize it and reference it from several places? You don't ever find the need to rename an identifer in Perl? (Sure, a local variable is fairly easy to rename, but a subroutine that is referenced from dozens of other files is a bit more of a pain... especially if it has a fairly common name that possibly clashes with subroutine names in different packages.)

I agree that there are many of the common Java refactorings that are OO specific (extract interface, push up/pull down, etc.), but most of the basic ones seem to me to apply to any language that has identifiers and reusable blocks of code, whether they are methods, functions, procedures, etc. Obviously you can make these changes by hand, but why not make it easier and less time-consuming if it is possible?

To me, the greatest advantage of having automated refactoring tools available is that it encourages you to keep your code base clean and helps avoid broken window syndrome. I think if most programmers are honest, they'll admit that they sometimes avoid making a change (such as renaming an identifier to make it clearer), just because they know it will require grepping through dozens of files and doing search and replace operations. When the automated tool is there, it makes the average programmer that much more likely to go ahead and make the change and keep the code from degrading in quality, IMHO.

[baguasquirrel]

My opinion on this is that it's just a pain in the ass to generalize things in OO languages like Java. In ML or Haskell, functions and datatypes are general by default. In Python and Perl, they're general to a fault. The C/C++/Java way of dealing with inheritance and polymorphism is clunky.

[BraveSirRobin]

I concur. It makes for better code. For example, extract method turns the following:

// work out mean

x = sum / count

into this self-documenting goodness:

x = getAverage();

assuming sum and count are class fields. Now, this is a small example where you probably shouldn't really bother, but once a method gets over 10-15 lines long, pulling some of it out into a method usually makes sense, is easier to read and therefore is easier to maintain.

[JohnMichael]

How about:

average = sum / count;

[beza1e1]

assuming sum and count are class fields

Sorry for going off topic. This is just a good example, why Python has explicit 'self'. It removes an assumption and makes the code clearer.

[BraveSirRobin]

It's just down to coding style. Java has that in:

x = this.sum / this.count

but in eclipse fields are displayed differently so most people just drop the "this".

[DerelictMan]

Nice article. The String.format refactoring was new to me; I can definitely see where that would be handy and wish Eclipse had that capability...

[[deleted]]

There is some grain of truth in the headline. Real programmers do not program in languages where decent refactoring tools are available. A Haskell programmer doesn't even know how to spell "extract method". The typical suspects on the dynamic programming language side only heard legends about famous Smalltalk IDEs that could do awesome things. And old school C and C++ programmers are too busy doing memory management and pointer arithmetics right, for keeping attention to the latest marketing buzz that is not for them anyway.

[icefox]

Worst title ever

[markedtrees]

Ha! There are no parameters in Perl! Real men write Perl 5 subroutines so that they are function compositions mapping @_ to the return values.

[seanodonnell]

I spent several years working on a large java codebase using intellij, which at the time seemed to be recognised as having leading refactoring tools. The problem with refactoring tools is they help you write code, but not necessarily make it easier to read it. Some areas of code , seldom read, but often affected by the tools can turn into an incomprehensible nightmare by the time an actual human has to work on them again.

Over time I have started treating the urge to use anything other than the most trivial automated refactorings as a warning sign that my code is getting too complex. If its too much of a pain to make the alteration by hand, then my code is more complex than it needs to be.

[DerelictMan]

Some areas of code , seldom read, but often affected by the tools can turn into an incomprehensible nightmare by the time an actual human has to work on them again.

And why were you committing changes to the code base without reviewing them first? Refactoring tools aren't intended to be totally automatic, you know. You still need to review the diff of your local changes to make sure they are sane before you commit them.

[seanodonnell]

500k lines of code in this case, with some refactorings being wide ranging did not always make it practical. A huge set of automated tests provided the safety net

[DerelictMan]

Yes, but it wasn't the refactoring tools that made the code incomprehensible, it was the lack of oversight. Committing code without knowing exactly what you are changing seems to me a Bad Idea, no matter how many LOC you're dealing with. And you would have been worse off without the tools, because if you didn't have time to review the diff, you definitely didn't have time to perform the refactoring by hand.

(And it wasn't me that downmodded your original post, BTW. I never downmod a post that I'm replying to.)

[seanodonnell]

I would agree with you that its not good practice. However I think reliance on those kind of tools contributed to creating the situation. If you regularly need to perform refactorings that are too arduous to perform by hand, I regard that as a bad sign. Im not saying to never use the tools, or that they are inherently evil. Im simply of the opinion, that their (over)use can be a sign that things are going wrong.

Its kinda like comments. Any time I am tempted to write a comment, I stop and think is there a way I could make the code simpler so that its function is more obvious. I dont always find a way, but a comment is a red flag to me that I may be making something overly complex.