views:

188

answers:

4

I'm working in a java project where a big part of the code was written with a formatting style that I don't like (and is also non standard), namely all method parameters are in uppercase (and also all local variables).

On IntellJ I am able to use "Analyze -> Inspect Code" and actually find all occurrences of uppercase method parameters (over 1000).

To fix one occurrence I can do "refactor > rename parameter" and it works fine (let's assume there is no overlapping).

Is there a way to automagically doing this refactor (e.g: rename method parameter starting with uppercase to same name starting with lowercase)?

+6  A: 

I'd advise that you think about a few things before you do anything:

  1. If this is a team effort, inform your team.
  2. If this is for an employer, inform your boss.
  3. If this is checked into a version control system, realize that you'll have diffs coming out the wazoo.
  4. If it's not checked into a version control system, check it in.
  5. Take a backup before you make any changes.
  6. See if you have some tests to check before & after behavior hasn't changed.

This is a dangerous refactoring. Be careful.

duffymo
Also look for `Class.forName` - they mean "DON'T TOUCH!"
Thorbjørn Ravn Andersen
I disagree with the comment that this is a dangerous refactoring. Renaming method parameters, especially, is about the safest refactoring you can do. Agree you should inform your team, but no need to make a whole project out of just renaming stuff...
romacafe
Dangerous because of the scale. I would agree that renaming a variable is innocuous, but if the whole project is written incorrectly you have a greater probability of missing something and borking the whole thing. There was no indication that the OP planned to inform anybody about this move. An opportunity to educate and inform would have been lost. But you're entitled to your opinion.
duffymo
+5  A: 

I think what you need to do is use a source code parser like javaparser to do this.

For every java source file, parse it to a CompilationUnit, create a Visitor, probably using ModifierVisitorAdapter as base class, and override (at least) visit(MethodDeclaration, arg). Then write the changed CompilationUnit to a new File and do a diff afterwards.

I would advise against changing the original source file, but creating a shadow file tree may me a good idea (e.g. old file: src/main/java/com/mycompany/MyClass.java, new file src/main/refactored/com/mycompany/MyClass.java, that way you can diff the entire directories).

seanizer
This is quite a lot of work though!
krico
Definitely. It must be complicated to work, because you have changes on all levels. The only sensible alternative I can think of would be to script the IDE.
seanizer
In the end this actually was the solution. Was not so much code in the end, didn't change the formatting of the existing code, only the parameters.
krico
A: 

I am not aware of any direct support for such refactoring out of the box in IDEs. As most IDEs would support name refactoring (which is regularly used). You may need to write some IDE plugin that could browse through source code (AST) and invoke rename refactoring behind the scene for such parameter names matching such format.

Siri
A: 

I have done a lot of such refactorings on a rather large scale of files, using TextPad or WildPad, and a bunch of reg-ex replace-all. Always worked for me!

I'm confident that if the code is first formatted using an IDE like Eclipse (if it is not properly formatted), and then a reg-ex involving the methods' signature (scope, return-type, name, bracket, arg list, bracket) can be devised, your job will be done in seconds with these tools. You might need more than one replace-all sets of reg-ex.

The only time-taking activity would be to come up with such a set of reg-ex.

Hope this helps!

Aditya Jha