
AutoRefactor: Eclipse plugin to automatically refactor Java code bases - based2
https://github.com/JnRouvignac/AutoRefactor
======
pron
See also Jackpot[1][2] (James Gosling himself was involved with the project)
which is now integrated with NetBeans.

For example, given the rule:

    
    
           $1.isDirectory() :: $1 instanceof java.io.File
        => !$1.isFile()
        ;;
    

It will rewrite this:

    
    
        java.io.File testFile = new java.io.File("/tmp");
        if (testFile.isDirectory()) {
            System.err.println("/tmp is a directory");
        }
    

into that:

    
    
        java.io.File testFile = new java.io.File("/tmp");
        if (!testFile.isFile()) {
            System.err.println("/tmp is a directory");
        }
    

Another cool feature is that simply placing the rule files in a library's
META-INF/upgrade directory, will activate them in the IDE, offering automatic
refactoring to users of the library (i.e. if the library is in your project's
classpath).

Jackpot is used extensively by NetBeans.

[1]:
[https://bitbucket.org/jlahoda/jackpot30/wiki/Home](https://bitbucket.org/jlahoda/jackpot30/wiki/Home)

[2]:
[http://www.devoxx.com/display/DV11/Jackpot+3.0+-+Large+scale...](http://www.devoxx.com/display/DV11/Jackpot+3.0+-+Large+scale+custom+refactorings+made+easy)

~~~
JnRouvignac
I am not a fan of Jackpot. Such DSLs are hard to build to keep expressiveness,
and yet, they remain hard to use for the user. I am a lot more enthusiastic
about the approach taken by Refaster.

------
delecti
After reading through about half of those examples, I can't go on.

The only one I saw that was potentially useful was the multi-catch. Half of
the rest were things I had never even seen, and couldn't imagine letting slip
by a code review (who uses control flow without brackets?), and the other half
were so trivial that I wouldn't even waste the time to run the tool for them
(why is the non-null case even preferable to do first? most people I know
prefer the input validation step first anyway).

~~~
JnRouvignac
I am the author of AutoRefactor. If you only need multi-catch refactorings and
have never seen the other pieces of code, then you are the luckiest Java
developer I have heard off. You are probably working on a green field project
with a small team of exceptionally talented people. For people not in that
case, chances are they are inheriting a very large code base originally
written with Java 1.4 or (shudder) even earlier. They are working with some
people that never manage to get the simplest indentations right, let alone the
code patterns you saw. The size and age of the code base made for numerous
failed attempts at running checks type. Finally, the team is so big that no
human can review all the code changes pre or post commit. Believe me, this
exist and I think this is probably most of the code written.

Concerning the not null case, I agree this one is very subjective. I hesitated
a lot before adding it. It is not as broad as what you think it is. It is only
touching if statements when the then and else clauses are similar.

Say if (o == null) return null; else return o.toString(); I am arguing that
the cognitive load is less important when the if statement is inverted. i.e.
if (o != null) return o.toString(); else return null; Or with ternary
operator: return o != null ? o.toString() : null;

You can disagree and then not run this particular rule.

~~~
delecti
Admittedly, none of the code I work with on a regular basis is older than ~4
years, but some of that has changed hands several times (hot potato project
nobody wants to own), and actually _still_ runs on Java 1.4.

I suppose I'm willing to accept that I've been lucky though, and god help
anyone whose code has the sorts of problems I wrote off as being unacceptable.

------
manyxcxi
I'm viewing the code from my phone, so I have not looked through the entire
repository to understand the styles that you can define and apply (if that's
possible) but the sample ins and outs are definitely the type of things we
document in our team best practices. I've generally fallen into the IntelliJ
IDEA crowd the last view years and have found it to be VERY customizable and
able to do a lot of the refactoring I see in the examples. As well as new line
cleanup, max width, spaces/new lines for brackets, parens, and braces, etc.
etc. The question I have (and the reason for me explaining that I haven't had
a chance to properly review the posted repo) does the library go beyond that
or simply add this missing functionality to Eclipse? Kudos though for his
development though, I found the ability to define language style guides via
configuration and pass them out to my team and set the formatters to run on
save has cleaned up our code bases mightily. This is absolutely useful work.

Off topic: I love what Eclipse (and the many great people behind it) has given
to me over the years and I still use Eclipse based derivatives (Android
development) but a couple years with IDEA and I can't imagine going back.

UPDATE: I just saw a link to the samples HTML and this appears to go beyond
what IntelliJ offers in some cases (as far as I can tell).

------
overgard
Why? (I don't mean that sarcastically: what's the idea?)

~~~
alok-g
I have seen many developers who write the type of code that this tool fixes. I
thereby love it. (Note: I am not associated with this in any way).

In case your question is why bother to fix to begin with, even such simple
simplifications make the code easier to maintain and to apply higher-level
refactoring.

~~~
RMarcus
I think some examples would go a long way.

~~~
mullr
[http://autorefactor.org/html/samples.html](http://autorefactor.org/html/samples.html)

------
reagency
Google recently published a paper about their extensive work in automated code
cleanup:

[http://research.google.com/pubs/pub43322.html](http://research.google.com/pubs/pub43322.html)

And their open source refactoring system:
[https://github.com/google/Refaster](https://github.com/google/Refaster)

~~~
JnRouvignac
Thanks! I will take a look.

------
JanecekPetr
This is great! In a bigger team and/or with an old application, I tend to do
these changes manually, all the time, for every piece of code I touch. And
while in the long run things get better, it's inevitably a losing battle if
the others don't care. Thank you for putting your time into this project!

~~~
JnRouvignac
I am happy if it helps you too

------
TheLoneWolfling
I wish these things were more language-agnostic.

There are all sorts of fancy refactoring tools out there, and most (all?) of
them seem to be intimately connected with the language in question.

I mean: take compilers for example. GCC isn't C-only. Or rather there are lots
of compilers built around the same framework. Why can't it be the same for
refactoring tools? They both are doing effectively the same thing, after all.
Turing one form of code into another form that's better, for some definition
of better. The distinction being that compilers tend to not have the input
language be the same as the output language.

~~~
JnRouvignac
Interesting question. What would prevent this to happen indeed?

One reason I can think of is that for GCC all input languages are converted to
the same intermediate representation (IR). From there, it's easy to apply the
same optimisations, generated code, etc.

For refactoring tools, I have never heard of such IR. The benefits of going
for an IR are not obvious either. The drawbacks are huge: a lot more code,
difficulty to build an IR rich enough to represent the semantics of all input
languages, and there's an extra mapping to go back to the original code by
keeping indentation and formatting.

While it is more obvious for GCC: you need another representation than the AST
to compile to assembly, optimisations are run on the IR, there is no need to
take care of the original source formatting.

Languages also have very subtle differences in meaning/behaviour making it
harder to reuse refactorings across languages.

Maybe it's possible to go with your idea, but I think it would require a big
team working on it. Who's willing to spend the money or the time when the
current approach seems satisfactory?

~~~
TheLoneWolfling
I always thought that refactoring tools should _be_ compilers.

That way you can reuse all of the parsing code / DCE code / flow analysis /
etc / etc.

The extra mapping is something a "normal" (i.e. single-language) refactorer
has to do anyways. Assuming its a half-decent refactoring tool its not just
doing a find-replace.

The subtle differences / drawbacks you mention a compiler also has to deal
with. Actually, everything you mention a compiler also has to deal with. You
could say the same about compilers (there's no actual need for an IR with a
compiler, for instance. You can operate on the AST directly. And you don't
need to build an IR rich enough to keep semantics in all languages unless
you're supporting multiple languages. Etc. Etc.) And yet we have GCC.

~~~
JnRouvignac
I agree the drawbacks equally apply to GCC. I agree a simple compiler does not
need an IR. Some compiler optimisations cannot exist without an IR.

However I was wondering where a refactoring tool would need an IR. I found
one: a CFG. For this, I need a three-address code representation. As a
hypothesis, let's suppose I can build one that is independent from the input
language. Once I have found how to refactor it, I then need to describe which
code must be rewritten to what, in the input langage. This is the part where I
find it very hard to do. I have the impression it will fall short here.

That would be an interesting experiment :)

------
wtetzner
Does anyone know if this plays nicely with Lombok?

~~~
orangecheese
I guess it might depend which features of lombok you use. Lombok vals don't
comply with the Java language spec so you might have issues there (as so many
other tools e.g. IntelliJ). Friends don't let friends use Lombok...

~~~
wtetzner
Instead friends let friends write and maintain enormous amounts of boilerplate
when they could have just used @Value?

~~~
orangecheese
The fact that you are resorting to DIY language extensions rather than picking
a more appropriate language for the job should tell you everything you need to
know.

~~~
wtetzner
Haha, I completely agree with you. Unfortunately I didn't get to pick the
language.

