Yes, you're right. But a whole bunch of people don't need or use things like automatic refactoring, and more often than not write better code than the people who do.
I don't use IDE's and I love Emacs, but sorry, for "more often than not write better code than the people who do" I feel like I have to invoke "citation needed"...
The automatic refactoring on IDEs are error proof (I'm thinking about eclipse and java here). Saying that you can do a line without a ruler is one thing, but saying your line will be straighter, I really doubt it.
IDEs are important for people that do refactorings. If you don't, fancy IDEs will slow you down.
I don't do refactorings that I'm not sure if they will break my code. It's the same reason I don't code with dinamically typed languages and avoid using reflection.
How do you know that the automatic refactorings in your IDE are "error-proof"? I've no experience to suggest otherwise, but it strikes me as a bold claim.
Presumably, you've got a suite of unit tests etc that you are using to verify your code still works post-refactoring. The same test suite would of course work outside of an IDE environment, so I don't think correctness is a valid argument here (but I agree that speed of refactoring is).
I work with smalltalk and java/eclipse so what I say come from this background.
With statically typed languages and a IDE to aid, refactorings like rename, pull up, pull down, extract interface and such can be done without changing the code behaviour (if your code don't use reflection).This is a characteristic of statically typed languages, not IDEs, but IDEs can do it automatically.
You could do this refactorings without a IDE, but not with text replace. For example, if you need to change the name of a method, category(), and two unrelated classes implements it, your refactor using text replace will change the method signature for both classes. You need to check every place where the code will be changed, and if your codebase is too big with too many calls, this is nearly impossible. The IDE rename the method calls based on the varible type, without risks of errors, if the refactoring is not possible eclipse warns you.
Yes or no. Static code transformation with well defined equilivency is many orders of magnitude more reliable than the error finding rate of a code reviewer.
You still review to make sure it was an improvement, and to make sure that the person making the changes didn't make the mistake. But you don't review the correctness of the transformation itself, at least not any more than you need to review the original code.
Never said that smalltalk is statically typed, I said I work with both on my job. A refactoring don't change the code behaviour by definition. I don't need someone to review my refactoring to look for errors from an automated refactoring, maybe to tell me that the refactor didn't improve my code.
Isn't this what automated unit and performance testing is for? If a refactor (or any code change) causes slippage on any of those indicators it should be flagged or rejected.
There are people who write bad code, with and without IDEs. There are people who write great code, with and without IDEs. I suspect that everyone who writes great code does refactoring. Some prefer to do it manually, and some prefer the automation.
