Next: , Previous: Handling of case exceptions, Up: Editing Files


5.8 Refactoring

GPS includes basic facilities for refactoring your code. Refactoring is the standard term used to describe manipulation of the source code that do not affect the behavior of the application, but help reorganize the source code to make it more readable, more extendable, ...

Refactoring technics are generally things that programmers are used to do by hand, but which are faster and more secure to do automatically through a tool.

One of the basic recommendations when you refactor your code is to recompile and test your application very regularly, to make sure that each of the small modifications you made to it didn't break the behavior of your application. This is particularly true with GPS, since it relies on the cross-references information that is generated by the compilar. If some of the source files have not been recompiled recently, GPS will print warning messages indicating that the renaming operation might be dangerous and/or only partial.

GPS currently provides the following refactoring capabilities:

•Rename entity
Clicking on an entity in a source file and selecting the Refactoring/Rename menu will open a dialog asking for the new name of the entity. GPS will rename all instances of the entity in your application. This includes the definition of the entity, its body, all calls to it, etc... Of course, no comment is updated, and you should probably check manually that the comment for the entity still applies.

GPS will handle primitive operations by also renaming the operations it overrides or that overrides it. This means that any dispatching call to that operation will also be renamed, and the application should still work as before.

•Name parameters
If you are editing Ada code and click on a call to a subprogram, GPS will display a contextual menu Refactoring/Name parameters, which will replace all unnamed parameters by named parameters, as in:
             Call (1, 2)
          =>
             Call (Param1 => 1, Param2 => 2);

•Extract Method
This refactoring is used to move some code from one place to a separate subprogram. The goal is to simplify the original subprogram, by moving part of its code elsewhere. GPS takes care of finding which parameters the new subprogram should have, whether they should be "in", "in out" or "out" parameters, and whether the new subprogram should be a procedure or a function. It also replaces the code in the original subprogram by a call to the new subprogram.
             procedure Proc (Param1 : Integer) is
                Local1 : Integer;
             begin
                Local1 := Param1;        --  line 4
                Local1 := Local1 + 1;    --  line 5
                Local1 := Local1 + 4;
             end Proc;
          
          When lines 4 and 5 are extracted, we get:
             function New_Method (Param1 : Integer) return Integer is
                Local1 : Integer;
             begin
                Local1 := Param1;        --  line 4
                Local1 := Local1 + 1;    --  line 5
                return Local1;
             end New_Method;
          
             procedure Proc (Param1 : Integer) is
                Local1 : Integer;
             begin
                Local1 := New_Method (Param1);
                Local1 := Local1 + 4;
             end Proc;

The above example, albeit trivial, shows in particular that GPS knows how to find which parameters should be transfered to the new subprogram.

GPS will use, for the parameters, the same name that was used for the local variable. Very often, it will make sense to recompile the new version of the source, and then apply the Rename Entity refactoring to have more specific names for the parameters, or the Name Parameters refactoring so that the call to the new method uses named parameters to further clarify the code.

This refactoring is only available if you have selected at least a full line of text, not a partial selection in a line of text.