Refactoring and Code Generation

Overview | Refactoring and Code Generation

The process of refactoring involves several logical steps - initial condition checking, user input gathering, final condition checking, generation of change sets, user review of changes, and change committing. Tools may need to repeat steps as required, eg. if further information is needed, or if there would be a semantic problem created by the refactoring, the user may get a chance to resolve the problem.

Precondition checking

Preconditions are basic conditions which must be met for the refactoring to be possible. They usually include that the project does not have any parsing errors, and that the location where it is to be initiated is a location which can accomodate the refactoring (eg. extract method should have a portion of a method selected in the editor).

These conditions may be run often to present the state to the user, so they should be efficient; save any complex analysis for later.

User input gathering

Here the user is presented with a user interface to enable the efficient gathering of information required to undertake the refactoring. This may take the form of a wizard for complex refactorings, or a popup notification for simpler refactorings such as an object renaming.

Final condition checking and change set generation

Once the user input has been collected, the tool should be in a better position to evaluate whether the refactoring is possible and will generate semantically correct changes. If there are no issues, the tool should proceed to generate change set(s).

Ideally, no more than one AST should be stored in memory at once in order that refactoring of complex projects proceeds without requiring excessive system resources. Once the change set is finalised, request for it to be translated into a KDevelop::EditorChangeSet.

User review of changes

The editor change sets will be optionally presented to the user for review before applying to the code base.