RFactor: Ruby Refactoring Support for Text Editors

Posted by Mirko Stocker on Mar 04, 2009

Sections

Process & Practices,

Development

Topics

Agile ,

Ruby ,

IDE ,

Agile Techniques ,

RubyGems

Tags

ParseTree ,

IDEs ,

Refactoring

RFactor is a Ruby gem that aims to provide automated refactoring support for your favorite text editor. Don't we have IDEs that support refactoring? Yes, but RFactor developer Fabio Kung believes that "most of Ruby developers do not use IDEs" and that a text editor is good enough.

Automated refactoring isn't a trivial task, and involves several complicated activities, like source code analysis to determine scopes and usages. It is also necessary to have a good strategy to modify the code without messing up the user's formatting.

Right now, RFactor is still quite young and supports only Extract Method with some limitations. We talked to Fabio Kung to learn more about RFactor.

RFactor uses ruby_parser, which returns the parsed Ruby AST as s-expressions (sexp). But how do you get the Ruby code back from s-expressions?

My initial idea is to use sexps just to support some refactorings. I'm using them to help me take decisions about how to refactor code. What variables can be considered local and what must become arguments, when I extract a method? When I extract a variable, which code should be modified to use the newly created variable?

I'm not direct modifying sexps to produce code; my approach was to modify the source code text directly. The sexp is there mainly to help me decide which things should change, based on the current scope (and to find what is the current scope).

Once I've used sexps to decide what is going to be modified, I extract line and column numbers, so I can directly modify the code written be users.

But wouldn't it be much easier if you could just re-generate new code from the sexps?

ruby2ruby is another awesome project from Ryan Davis, which outputs ruby source code back from sexps. I considered using it before, but I wouldn't be able to maintain comments and user formatting with it.

Through this path, I would have to include comments and formatting nodes (such as newlines, spaces and tabs) in Parse Trees. It is certainly an alternative, but much more complex. This is why I've decided to use sexps just to discover line and column numbers and then I manipulate the source code text directly. 

This approach has been enough for simple refactorings (which are my goal) so far. But I'm sure it isn't enough for some more complex refactorings such as move/rename. Those refactorings require different approaches. In the rename/move case, for example, I'm considering using Ack (improved grep) to find potential matches. Then, I would use heuristics (backed by sexps) to suggest places to be changed, asking users what they want to change. It is very hard to do, but good IDEs already have good implementations for those things. 

In spite of it, I won't bother that much with complex refactorings; they aren't my current goal. I'm not trying to turn TextMate and friends into complex IDEs. We don't have any refactoring support for good text editors. Let's concentrate on have a simple set first.

So, what is the plan for the future?

So far, Rfactor is very simple, because it can only extract methods for code inside other methods; i.e.: no support for code outside methods yet. Also, it isn't trying to infer method parameters and return. This is one of the the things I want to support. Sexps can tell what should be local variables and what can't. Another thing to consider is replacing similar code with a call to the newly created method.

I'm also studying other implementations such as Python's Bicycle Repair Man, Eclipse RDT, Smalltalk Refactoring Browser and whatever that has a permissive license (Netbeans? RubyMine?). Phil Dawes (from Bicycle Repair Man) has already given me useful insights.

More refactorings are also in the plans:

• Extract Method
• Extract Variable
• Extract Class
• Extract Module
• Rename/Move using Ack

Unfortunately, I'm only one man and I'm working on these things only for fun, in some of my free time. As in most of the open source projects, any contributions would be very appreciated.

More on RFactor can be found on GitHub as well as on Fabio's blog post on RFactor, and there also exists a TextMate bundle.

RFactor is another step towards having Ruby source code tools written in Ruby, other examples are static analysis tools which also use ParseTree or ruby_parser to get at Ruby ASTs.

If you're a text editor user, do you miss refactoring support? Are there other IDE features that you would like to see integrated into your editor?

1. Back to top

   SLIME tool

   by Werner Schuster

   Would be interesting to see something SLIME for Emacs and LISP for Ruby.
   wingolog.org/archives/2006/01/02/slime
   common-lisp.net/project/slime/
   
   Basically, it's a LISP backend that implements all kinds of logic for doc lookup, syntax/semantic coloring, etc. Frontend (eg Emacs) and Backend communicate over a protocol - which means you could write, say, a different frontend (eg. for vim) for SLIME but get to reuse the functionality on the backend.
   
   I'd say this is a better approach than rewriting the same functionality for every Ruby IDE or Ruby editor support the way it's done now. Obviously - the frontend would still be a lot of work, if only to translate the backend features to the IDE or editor metaphors; but the basic implementation would be shared. Also: with JRuby as mature Ruby on the JVM, Java-based IDEs could run the Ruby backend in the same JVM process.
   
   I wonder if enough Ruby editor dwellers can get together to pull something like this off.

   Reply

• Older >