Community
Participate
Working Groups
When a variable name is not found within a method, the compiler proposes a quick fix that adds a new parameter to the method. This fix only affects the current method in the current file, but the could be invoked by another method in either the same file or another. A refactoring action would be better, as 90% of the times refactoring is required just after adding the parameter. The new quick-fix routine could pop up the refactoring dialog with the suggested parameter already loaded in the list and the cursor placed in the "Default value" column. Perhaps there could be two quick-fixes in the quick-fix list, offering both the old and "refactoring" versions. Maybe this can happen with other quick-fixes?
At the moment we separate the two: Quick fix and refactoring. But I see what you mean.
Yes I second this. What good are quick fixes if they break your code rather than fix it? That just makes them a hindrance. What we need is a quick fix that does the refactoring in one step without any dialogs. See IntelliJ IDEA for inspiration on how this should work.
To make the refactoring UI more light weight (less dialogs) is one direction we're going, see rename refactoring in 3.3 M5. Hoever, quick fixes/assist will always be a code manipulation utility, separate from refactoring. They are an editing aid like code assist that need to be fast and local. Whenever multiple files are touched, you want to know that so this needs to be done a controlled way.
I don't have access to IDEA, so please give a more specific description of how you think we should improve the 'Add parameter' feature.
It should work like the new rename refactoring does, i.e. you're editing/changing it "inline" without having to bring up a dialogue. If there are any warnings the dialogue are brought up otherwise the refactoring is just done. I.e. if you're having Eclipse remove a parameter on a method it should invoke the remove parameter refactoring without asking any questions, giving you the dialogue if there are any warnings. The point is that invoking the change signature refactoring is a very cumbersome way to do something that should be SIMPLE, i.e. having Eclipse remove an unused parameter for example. At the moment the remove parameter etc quick fixes are kind of useless since they break your code when you use them. (I'm assuming here that you're working with methods that are actually called, which is going to be the case the vast majority of the time.) I understand you have an investment in having the concept of a "quick fix" adhere to a particular thought mold pattern. If that is the case I suggest we think of a solution that addresses the larger problem outside of the realm of quick fixes, i.e. having a working way to QUICKLY and EASILY invoke relevant refactorings on elements, in addition to (or instead of) the current quick fix style of doing things which only does local edits. The goal being that Eclipse would be more productive to use. This has already been spearheaded with the new rename refactoring, so why not continue with other useful productivity improvements in the same vein, like the remove parameter refactoring etc? Another question to consider is why would anyone actually use quick fixes that break your code? I understand that you're wanting quick fixes to be local edits only, which makes me wonder if it's useful to only have quick fixes in situations where multi-file edits are what would be required? What's the point of having a feature work in a particular way if it makes the user less rather than more productive? This is the area where IntelliJ IDEA has ALWAYS had the upper hand over Eclipse, i.e. productivity features. If we sort this out Eclipse will be the best IDE on the market. At the moment IDEA beats Eclipse hands down in terms of pure code editing/refactoring productivity. I'd like to change that.
*** Bug 328203 has been marked as a duplicate of this bug. ***
*** Bug 333923 has been marked as a duplicate of this bug. ***
*** Bug 356163 has been marked as a duplicate of this bug. ***
*** Bug 327423 has been marked as a duplicate of this bug. ***
*** Bug 532441 has been marked as a duplicate of this bug. ***
