Rational snuck a feature in under the radar that might signal a sea change for the product.
What is refactoring, and why do you care?
Refactoring in the broadest sense refers to an intelligent, comprehensive change to your program source. The least complicated example is a simple rename, while a more complex case might involve pulling out all occurrences of a common piece of code and putting that into a callable routine.
Refactoring is important because it allows you to more easily make systemic changes to a program that might otherwise just be too much to manage. This helps you to overcome what I like to think of as “architectural inertia,” the natural tendency to not want to implement new technological approaches for fear of breaking existing code, even if those new approaches can bring significant advantages to your programs.
The New Refactoring in RDi
So with very little fanfare, in the 9.5.1.1 fixpack of RDi, IBM introduced the concept of refactoring for ILE RPG. That's right, it's not even a point release; it's a fixpack of a point release. The implementation is quite straightforward: highlight the field or procedure you wish to rename, right-click, and select Refactor > Rename. The name you selected will pop up in a dialog, and you can choose a new name for it. Let's take a quick spin. Here's my program:
ctl-opt actgrp(*new) option(*srcstmt:*nodebugio);
dcl-s myVariable char(1);
dcl-s myVariable2 char(1);
dcl-ds myDS qualified;
allDone ind;
end-ds;
init();
dou myDS.allDone;
doSomething();
enddo;
*inlr = *on;
return;
dcl-proc init;
clear myVariable;
clear myVariable2;
end-proc;
dcl-proc doSomething;
myVariable += 1;
myDS.allDone = myVariable > 100;
end-proc;
It's a very simple program that doesn't do anything useful, but it allows me to illustrate a couple of points. First, let's just look at the basic mechanics of the refactor. As noted above, we start by highlighting something and then use the context menu (right-click) to select the option:
Figure 1: Use the context menu to select the Refactor option.
Alternatively, you could use the keyboard shortcut Alt+Shift+R to trigger the same action. One thing to remember: While on this program, the pop-up shows up almost instantaneously; on any program of more than trivial complexity, you will see an additional pop-up. It looks like this:
Figure 2: Before performing the action, the IDE must first parse your source code.
As far as I can tell, the IDE is going through your entire source program and looking for all the actual references to what you are renaming, as opposed to finding something similar or something in a comment. Since this is roughly akin to actually syntax-checking the program, this is not a trivial task. Depending on the size of your program, this could take a while. Once done, however, you end up with a simple pop-up:
Figure 3: You simply key the new name into this pop-up and hit OK.
Once you hit OK, the source code is changed. In our example, you end up with the following code:
ctl-opt actgrp(*new) option(*srcstmt:*nodebugio);
dcl-s myField char(1);
dcl-s myVariable2 char(1);
dcl-ds myDS qualified;
allDone ind;
end-ds;
init();
dou myDS.allDone;
doSomething();
enddo;
*inlr = *on;
return;
dcl-proc init;
clear myField;
clear myVariable2;
end-proc;
dcl-proc doSomething;
myField += 1;
myDS.allDone = myField > 100;
end-proc;
Notice that every instance of myVariable is now myField. The really important thing to notice, though, is that while myVariable has changed, myVariable2 has not. This is by design. Even though the fields are similar in name, they are not identical, so unlike a simple mass find and replace, the refactor action doesn't change myVariable2.
Preview Mode
There are cases where a blanket change just isn't a good idea. A really good example is copying a procedure, especially one where you've labeled not only the dcl-proc statement, but also the end-proc and perhaps even the dcl-pi. Let's say I have the following procedure:
dcl-proc returnTrue;
dcl-pi returnTrue ind end-pi;
return *on;
end-proc returnTrue;
Let's say further that I want to clone it into a procedure called returnFalse. I copy the lines, and then I highlight returnTrue and start going through the Refactor > Rename action. However, in Figure 3, rather than hitting OK, I instead hit Preview. Here's what I see:
Figure 4: The first panel of the Rename preview shows a summary of references.
This summary telling me how many references were found is nice, but the real meat of the preview comes in when I hit Continue:
Figure 5: The detail panel of preview mode allows you to selectively apply the rename.
This may be the most useful version of the new action. Here, I can apply the change to only the cloned version of the procedure by simply unchecking a few boxes. This might even convince me to put labels on my procedure interfaces again. Nah, not likely. But still, it's a very nice feature.
The Future
This is really just the first sally into the new (to RPG, anyway) world of refactoring. There are already requests out there for other forms of refactoring, from extracting constants to creating procedures. You can see more about the 9.5.1.1 release on the IBM website. You can also drill into more detail on the the whole refactoring concept. I said at the beginning that this might signal a sea change; if IBM gets serious about implementing more of these features, then I definitely see a possibility of the RDi tool becoming a way to facilitate fundamental system redesign. We'll see what the future brings.
Caveats
Refactoring isn’t a silver bullet. Perhaps the biggest problem is the entire idea of mod-marking, the technique of tagging every line of changed code with some sort of code that indicates the project that changed that line of code. A common practice is to use the first five characters of your RPG source line to contain the mod-mark. This technique is so ingrained into the fabric of RPG development that even the first incarnation of free-format RPG supported those first five characters. The refactoring option doesn’t currently support that technique, and I don’t expect that it ever will. Instead, I see the trend moving toward the UNIX “diff” style of version control, in which you run a command to show the differences between two versions. I don’t think that’s a reason to eschew the refactor tool, but be advised that the issue is there.
Also, there are times when a good old mass find-and-replace will work best. Whether it's changing the prefix for all fields in a file or changing a word that is part of a whole set of routines, sometimes the brute force method works best. Also, if you have procedure or variable names in your comments, those references will not be updated. But given what we're seeing in RDi, the future of RPG looks like it's moving ever more toward the rest of the world of programming languages, and we might be well advised to learn to work in that environment. Embracing the new refactor option is one way to start moving in that direction.
LATEST COMMENTS
MC Press Online