Today, after 15 weeks of hard work, I was finally able to hand in my Refactoring for Scala term project (its website is scala.ifs.hsr.ch, where you can also find the technical report). After a short break of four weeks, I will continue the project as my master’s thesis.

What has been achieved so far? After investigating the Scala compiler (nothing is more fun than learning a new language by reading it compiler’s source code, trust me), I started to create with a foundation to build the refactorings on. Refactorings basically just transform an AST, which has to be converted back to plain text afterwards (which is far more complicated than it sounds, trust me). This occupied me for the larger part of the project, and it still isn’t finished, but I was able to come up with a scheme that allowed me to leave it in an unfinished state and still being able to perform refactorings, at least good enough for a proof-of-concept.

The implemented refactoring is Extract Method; a perfect candidate because it is not too simple (with regards to the code transformatioms) and it looks much more impressive than e.g. Rename. Is it already usable? I’m not sure, it has not been tested with a lot of real world code (and usually when I did, it didn’t take me long to find new bugs, or rather things that were not yet implemented), but that will certainly be done in the near future. Another hurdle to using it is that you would need to install my modified Eclipse Scala plug-in (and I haven’t yet been able to create a working nightly-build including the Eclipse plug-in and all my stuff that would be needed).

For the near future, i.e. before the thesis, the plan is to implement organize imports, so I can bribe Miles Sabin into including the refactoring library in the Eclipse Scala IDE. After that, I’ll continue the project with a 20 week full-time thesis (~800 hours of work), where I hope to stabilize the existing Extract Method, advance the library so it can be used by other developers without knowing the inner workings of it, and to provide many new refactorings!

In the mean time, I highly appreciate any feedback. And keep an eye on this blog or follow me on twitter to hear the latest about the project.

I haven’t blogged in quite a while now. Actually, the last entry was to announce my term project on Scala Refactoring. My excuse is, I was hard at work! So without further ado:

class Demo1 {
  def demo1(i: Int): Int = {
    val a = i
    val b = a + i
    b
  }
}

Select the line with the assignment to b, murmur the incantation press some keys, et voilà:

class Demo1 {
  def newMethod(i: Int, a: Int): Int = {
    val b = a + i
    b
  }
  def demo1(i: Int): Int = {
    val a = i
    val b = newMethod(i, a)
    b
  }
}

It also works with multiple return values and when passing functions. Now, the code isn’t ready yet, and I have to concentrate on writing my report right now, so it might take a couple more weeks until I can ship something.

If you’re a Java programmer and haven’t yet heard of Scala, take a look at this nice Scala Tutorial.

What follows is my project proposal for my master term project (12 ECTS, ~360 hours of work, the same as a bachelor thesis actually). The project starts next week and will keep my busy for the next 14 weeks.

If Scala wants to succeed Java, it needs strong IDE support, and this includes automated refactorings. Although studies show that refactoring tools are underused, they still serve as a strong selling point to convince programmers to use an IDE (or even a whole language) over a simple text editor. Several Scala IDEs are under development, but all of them lack extensive support for refactoring.

I’ve worked on various projects implementing (Ruby, C++) and supervising (JavaScript, Groovy) refactoring tools. Taking advantage of these experiences, I believe that a sound refactoring engine can be built for Scala in due time.

Objectives

Scala should get an IDE independent facility to perform refactorings. This API can then be used by all IDEs and other tools to refactor Scala code – fostering collaboration to get truly great refactoring capabilities instead of several half-baked implementations from competing IDEs (as the situation with other languages – e.g. Ruby – is today).

The basis to create a successful tool is the code manipulation strategy, i.e. how the source is modified, and most important, how the changed source is obtained (formatting, comments, white-space). In the past, we at the Institute for Software experimented with different strategies but have yet to come up with a silver bullet. Therefore, the first focus of this project will be to analyze existing ways and to come up with a suitable code representation for this project. Additionally, Scala’s functional aspects (especially pattern matching) should lend itself ideally to the manipulation of tree-like data-structures.

Finally, to make the implementation of refactorings easier, several granularities of abstractions will be needed. Basic building blocks to modify the source trees (e.g. ‘move x to y’, ‘rename x to y’, ‘create a new X at y’) can then be assembled to complete refactorings (“cursor position is x, rename all references to ‘y’”) and exposed together with – probably already existing – query-operations (‘what can be renamed’, ‘what is located at the current cursor position’) and feedback (warnings, errors) through the API. The result of such a refactoring operation will be a set of diffs the IDE can then apply and show to the user.

Vision

To my knowledge there exists no language that has IDE independent refactoring support, and the only people creating new refactorings are the developers of the IDE. If this project succeeds, Scala will have a simple API to manipulate its source code on which refactorings and other code manipulation tools (e.g. quick fixes, code generators) can be built by Scala programmers and not only IDE adepts.

Desired Results

An API to do refactoring together with an implementation and ideally two reference users in the form of automated tests and an Eclipse plug-in. Whether these goals are realistic will be determined during the project and adapted if necessary. A more detailed project plan will be developed in the first week of the project, as soon as the effort can be better estimated with regards to the available environment (e.g. the richness and suitability of the AST).

Now, what do you think? How important is automated refactoring support for you in choosing an IDE or a language?