Perl Needs Better Tools
by Matisse Enzer |

Rename Subroutine/Method

The IDE should find all the calls to the subroutine throughout your project and offer to change them for you. You should be able to see a preview of all of the places a change could occur, and to accept or reject each one on a case-by-case basis. The action should be undoable.

Rename Variable

Like Rename Subroutine, this feature should find all occurrences throughout the project and offer to make the changes for you.

Change Subroutine/Method Signature

The IDE should be able to make reasonable guesses about whether each subroutine or method call is supplying the proper parameters. Partly this is to enable the real-time syntax checking mentioned above, and partly this is to enable you to select a subroutine declaration and tell the IDE you want to refactor it by adding or removing a parameter. The IDE should then prompt you for the change(s) you want to make, do its best to find all of the existing calls to the subroutine, and offer to correct the subroutine calls to supply the new parameters.

Obviously, this is an especially tricky thing to do in Perl, where subroutines fish their parameters out of @_. So the IDE would have to look carefully at how the code uses shift, @_, and $_[] in order to have a reasonable guess about the parameters the subroutine is expecting. In many common cases, though, a Perl IDE could make a reasonable guess about the parameters, such as in the following two examples, so that if you added or removed one, it could immediately prompt you about making corrections throughout the project:

sub doSomething {

    my $gender = shift;

    my $age    = shift;

    # Not too terribly hard to guess that $gender and $age are params

}



sub anotherThing {

    my ($speed,$direction) = @_;

    # No magic needed to guess $speed and $direction are params.

}

Move Subroutine/Method

This refactoring operation should give you a list or dialog box to choose the destination file in your project. The IDE should allow you to preview all of the changes that it would make to accomplish the move, which will include updating a call to the subroutine/method to use the proper class. At a minimum, the IDE should show you or list all of the calls to the subroutine so you can make the appropriate changes yourself. Ideally, the IDE should make a guess about possible destinations; for example, if $self is a parameter to the method being moved, then the IDE might try assuming the method is an object (instance) method and initially only list destination classes that inherit from the source class, or from which the source class inherits.

Change a Package Name

As with Rename Subroutine and Rename Variable, when changing a package name, the IDE should offer to update all existing references throughout your project.

Tree View and Navigation of Source Files and Resources

Another useful feature of good IDEs is being able to view all of the code for a project, or multiple projects, in a tree format, where you can "fold" and "unfold" the contents of folders. All of the modern graphical IDEs support this, even with multiple projects in different languages.

Being able to view your project in this manner gives you both a high-level overview and the ability to drill down into specific files, and to mix levels of detail by having some folders show their contents and some not.

For example, Figure 8 shows a partial screen shot from ActiveState's Komodo IDE.

Figure 8. Tree view of code in Komodo

Support for Creating and Running Unit Tests

Anyone who has installed Perl modules from CPAN has seen unit tests--these are the various, often copious, tests that run when you execute the make test part of the installation process. The vast majority of CPAN modules include a suite of tests, often using the Test::Harness and/or Test::More modules. A good IDE will make it very easy to both create and run unit tests as you develop your project.

Prev  [1] [2] [3] [4] [5] [6] Next