Like reference symbols in the various drawings indicate like elements.
A user may open a menu 110 of refactoring transformations, for example, by right-clicking on the selected identifier. The menu 110 includes a list of refactoring transformations from which a user may make a selection. In certain implementations, the list includes only the refactoring transformations relevant to the selected identifier or makes refactoring transformations that are not relevant non-selectable. Alternatively, a user may initiate a refactoring transformation by other means, such as by making a selection in the toolbar 102 or the menu bar 104.
Here, the user makes an “Encapsulate” selection, as indicated by dashed line 112. Encapsulation refers to hiding access to a variable using “getter” and “setter” methods or functions. The encapsulate refactoring transformation replaces instances of the variable in the source code with the “setter” function where an assignment is made to the variable and the “getter” function where the variable is used as an operand.
Alternatively, a user may select an “SKTGraphicView” identifier to undergo a refactoring transformation, as indicated by dashed line 114. The user may initiate a different refactoring transformation on the “SKTGraphicView” identifier, such as a renaming of the identifier.
In addition, other refactoring transformations may be performed. For example, one or more members of a class may be extracted and used to create a new super-class above the original class and below a parent of the original class. A class may be merged or inlined with another class. One or more members of a class may be pulled up from the original class to a parent class of the original class or pushed down to a child class of the original class. A method signature may be changed by adding, removing, or reordering parameters of the method. Language specific refactoring transformations may be performed, such as by converting a statement that loops through elements of an array to a particular loop syntax provided by the programming language.
For example, parsing and editing is complete for files 602 and 604 as indicated by their boldface font and the indication of the number of changes made as a result of the refactoring transformation. In addition, the files 602 and 604 have associated selection controls. The selection controls allow a user to select whether or not the refactoring transformation process will permanently apply the changes in the preview to the associated file. The refactoring transformation process is currently in progress for a file 606 as indicated by its boldface font and its lack of a change count. A spinning animation associated with the file 606 also indicates that the parsing and editing of the file 606 are in progress. After the refactoring transformation process is complete for a particular source code file, a user may review and analyze the edits made to the source code file. This may occur while the refactoring transformation process continues on another source code file in the source code module. That is, the refactoring transformation is performed in a stepwise fashion to allow a user to analyze and review edits resulting from portions of the refactoring transformation while the refactoring transformation is still in progress on other portions of the code module.
The refactoring UI 200 presents a preview area 704 that includes a pre-refactoring transformation representation 706 of the selected source code file and a post-refactoring transformation representation 708 of the source code file. In addition, the preview area 704 indicates one or more individual edits using highlighting, as represented by dashed line 710. A user may review the edits and make changes to the edits as the refactoring transformation continues on one or more other source code files.
If one or more preconditions associated with the edit shown here generate non-critical errors and/or warnings, then a user may review the errors and/or warnings by selecting the errors and warnings control 404. A user may review errors and warnings while the refactoring transformation is in progress. In certain implementations, a user may select an error or warning, while reviewing the errors and warnings list, to present an associated source code file and its edits in the preview area 704.
In certain implementations, an edit category contains instructions to manipulate representations of the program other than the text representation of the source code. For example, if the program is stored internally in the editor as a parse tree, the edit category may describe the changes in terms of changes to the parse tree. If the editor is maintaining additional data structures such as dataflow graphs, then the edit category can specify how the dataflow graph is changed by the transformation.
In certain implementations, a method other than the previously described four categories may be used to define the precondition categories. Particularly, in programming environments without a “file” concept this is the case. For example, precondition categories may be divided according to functionality, such as on a class and/or function basis, or at a higher conceptual level than the class/function level, such as by user interface management, database access, and internal processing. In general, the precondition categories divide the testing of the preconditions into groups that may be performed in a stepwise fashion. This allows a user to review and analyze results of one or more precondition tests as one or more other precondition tests are performed.
Edits performed by the refactoring transformation are also organized into categories. In this example, there are two edit categories, that is, edits that can be performed after parsing and testing a file and edits that can be performed after parsing and testing all of the source code files 902a-e. For example, the refactoring transformation process may edit (910a-e) each of the source code files 902a-e to rename the “SKTGraphicView” identifier to “MyView.” After parsing, testing, and editing each of the files 902a-e individually and performing the final test (908), the refactoring transformation process may perform a final edit. For example, when an encapsulation refactoring transformation process is performed, a location for the setter and getter functions may be determined after all uses of the encapsulated variable have been determined. If the variable is only used in one source code file, then the setter and getter functions may be placed (912) in that source code file. Otherwise, if the variable is accessed in multiple source code files, then the setter and getter functions may be placed (912) in a file accessible by the source code files and declarations of the functions may be placed (912) in a file included by the source code files, such as a header file.
In certain implementations, a method other than the previously described two categories may be used to define the edit categories, such as the alternatives previously described for precondition categories. In addition, one or more edit categories may be added, such as an edit category (or precondition category) for refactoring transformations to be made to another code module as a result of the refactoring transformation to the current code module. For example, the renamed “SKTGraphicView” identifier may be used in a code module other than the “Sketch” code module. In general, the edit categories divide the editing of source code files in a code module into groups that may be performed in a stepwise fashion. This allows a user to review and analyze results of one or more edits as one or more other edits are performed.
Optionally, the process 1000 may test (1004) one or more initial preconditions. For example, the renaming refactoring transformation process may test (904) an initial precondition that verifies “MyView” as a valid identifier.
The process 1000 selects (1006) a source code file. For example, a user may indicate, via the refactoring UI 200, a particular order for processing the source code files by dragging and dropping the files in the list 402. The process 1000 may proceed sequentially through the list 402 of source code files.
The process 1000 tests (1008) one or more preconditions for the selected source code file. For example, the renaming refactoring transformation process may perform tests to determine the type of the “SKTGraphicView” identifier, whether the type may be renamed, and whether a local variable in the selected source code file already uses the new “MyView” identifier.
The process 1000 performs (1010) edits to the selected source code file. For example, the renaming refactoring transformation process may rename each instance of the “SKTGraphicView” identifier as the “MyView” identifier.
The process 1000 provides (1012) results to a user. For example, the refactoring UI 200 indicates, in the list 402, completed processing using boldface font, a selection control, and an indication of the number of changes. The refactoring UI 200 also indicates a refactoring transformation in progress using boldface font and a spinning animation. In addition, the refactoring UI 200 may present further results in the preview area 704, such as changes due to edits, or errors and warnings may be presented to a user in an error and warning list.
If there is another file to transform (1014), then the process 1000 selects (1008) another source code file. Optionally, if there are no more source code files to transform, then the process 1000 may test (1016) one or more final preconditions. For example, the renaming refactoring transformation process may perform a test to determine if a declaration of the “SKTGraphicView” was replaced. If not, the renaming refactoring transformation process may record an error or warning indicating that the refactoring may be incomplete.
Optionally, the process 1000 may perform one or more final edits to a source code module after making individual edits to the source code files. For example, the encapsulation refactoring transformation may determine a location for setter and getter functions, such as a source code file where accesses to an encapsulated variable occur or a library accessible by multiple source code files that access the encapsulated variable.
In some implementations, the host device architecture 1100 includes one or more processors 1102 (e.g., dual-core Intel® Xeon® Processors), a display device 1104 (e.g., an LCD), a source code repository 1106, a network interface 1108 (e.g., a Ethernet, USB, Firewire®), one or more input devices 1110 (e.g., mouse, keyboard) and one or more computer-readable mediums 1112 (e.g., RAM, ROM, SDRAM, hard disk, optical disk, flash memory, SAN, etc.).
The components of the host device architecture 1100 described above can exchange communications and data over one or more buses 1114 (e.g., EISA/ISA, PCI, PCI-Express) for facilitating the transfer of data and control signals between the component of the architecture 1100.
The term “computer-readable medium” refers to any medium that participates in providing instructions to a processor 1102 for execution, including without limitation, non-volatile media (e.g., optical or magnetic disks), volatile media (e.g., memory) and transmission media. Transmission media includes, without limitation, coaxial cables, copper wire and fiber optics. Transmission media can also take the form of acoustic, light or radio frequency waves.
The computer-readable medium 1112 further includes an operating system 1116 (e.g., Mac OS®, Windows® XP, Linux® OS), a network communication module 1118, a UI manager 1120, and a source code editing tool 1122. The operating system 1116 can be multi-user, multiprocessing, multitasking, multithreading, real time, etc. The operating system 1116 performs basic tasks, including but not limited to: recognizing input from the input devices 1108 and providing output to the display device 1104; keeping track and managing files and directories on computer-readable mediums 1112 (e.g., memory or a storage device); controlling peripheral devices (e.g., printers, external storage devices); and managing traffic on the one or more buses 1114. The network communications module 1118 includes various components for establishing and maintaining network connections and services (e.g., software for implementing communication protocols and services, such as TCP/IP, HTTP, sync services, etc.). The UI manager 1120 includes various software components for displaying and managing windows and related processes.
The source code editing tool 1122 further includes a refactoring transformation engine 1124, a parser 1126, an editor 1128, refactoring transforms 1130 and category definitions. These components provide the various processes and features described in reference to
A number of implementations of stepwise source code refactoring or re-writing have been described. Nevertheless, it will be understood that various modifications may be made to the disclosed implementations without departing from the spirit and scope of the invention. Accordingly, other implementations are within the scope of the following claims.