+1 Guillaume Berche wrote: > Subject: Extend refactorings to ones that can not be 100% automated but > assist programmers in performing remaining manual modifications. > > I read a discussion in the archive of this list from jetBrains people saying > they see few value to refactorings that can not be automated. I would like > to offer a different opinion on this. > > In such refactorings the UI support for the refactoring would be split in 3 > phase: > 1. usual preview > 2. execution of automated transformation > 3. iteration from the preview screen to the list of required manual changes. > > While this is true that such refactoring are less impressive that fully > automated ones, I believe they can still bring much value to the developer > because most of the work (usually in identifying necessary changes to be > made) is performed automatically. I believe in most situation, the potential > benefit of an tool concerns time necessary to perform the refactoring is > greatly devoted to identification of changes rather than performing the > change itself. I however agree that IDEA with its semantic search often > already reduces significantly this time, but I still believe there are great > remaining opportunities for improvements. Some examples I frequently ran > into with build 638: > > Suggestion 1: Move method refactoring for non-static method (for instance > up/down in a class/interface hierarchy). > > Whereas it can not be 100% automated such a refactoring provides the > following benefits: > - automatically identify dependencies and necessary updates > - automatically move method declaration > - support programmers in performing remaining manual modifications. > > Suggestion 2: Improvement to method signature change refactoring to support > modification of declared exceptions > > I would be nice if the method signature change refactoring would allow the > programmer to also modify declared exceptions. Then check if callers catch > blocks need to be modified (given the actual "surround with try/catch" this > should be easy to implement), and list the ones that need manual > corrections. Then the programmer can apply on those the "surround with > try/catch" code generation. > > Guillaume. >
_______________________________________________ Eap-features mailing list [EMAIL PROTECTED] http://lists.jetbrains.com/mailman/listinfo/eap-features
