Header

Scala Refactoring Term Project

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?

3 comments »
Header

How Old Is Agile Development?

Reading the following lines, it should be crystal clear to every professional that the text refers to some sort of Agile Development:

[..] we consider the design process as a recursive operation taking place in increments of, say, weeks. That is, after each increment, we aim at having a finished product [..]. In other words, we consider the product as always, from the very first few weeks onward, to be in the hands of users. A version of the product is always finished and available for use.

Now, how old is this quote? Certainly not more than ten years, that would have been my guess. Probably from the early XP days? Actually, the quote is from 1977‘s august edition of IEEE Computer. Interesting, isn’t it?

2 comments »
Header

Hello again!

Welcome to my new blog!

After almost 4 years of blogging at blog.misto.ch, I needed a change. The posting frequency constantly dropped and I’ve picked up twitter to post shorter messages, and most of the serious work I did ended up on InfoQ.

So, why even bother blogging anymore? Well, I’ll soon start my masters project and I want to have a platform to communicate about it1. I also feel (or rather hope) that this might interest a broader audience, thus the switch over to english and – in the wake of all these changes – also a fresh design23.

And now, some rules for this blog:

  1. Comments are to be written in English or they’ll get deleted.
  2. You may criticize my English (I’m all for improving my skills), but please only if you’re really sure and can back up your claim.
  3. Subscribe to the feed!
  1. If you’re curious, and as you’ve probably already guessed, I’ll bring automated refactoring support to Scala! But more on that in the following days.
  2. That, as I just realized today, also matches the color scheme of our bathroom.
  3. Aren’t these footnotes pretty?
11 comments »