[ANN] Rearranger plugin -- new version 1.2 released

The Rearranger plugin reorders class and class member declarations according to a user-specified order.

Version 1.2 adds the ability to group extracted methods with their caller(s). An extracted method is one which is called by another, except that getters and setters are specifically excluded.

If called by more than one method, extracted methods may be grouped with the first or last caller.

If an extracted method in turn calls another, the resulting tree of methods may be arranged in depth-first or breadth-first order.

A group of extracted methods at the same level in the tree may be arranged in the order they were called (usage order), in the order they originally had (before rearrangement), or alphabetically.

Overloaded methods may be forced into adjacent positions, overriding the ordering just described.

- Bug fix: avoid hanging IDEA.

See http://www.intellij.org/twiki/bin/view/Main/RearrangerPlugin for more details.

Please let me know of any problems you find!

-Dave

P.S. Here's a short list of outstanding feature requests:

- Ability to group methods together that implement an interface
- Global comment pattern control
- multiple constructor ordering
- overloaded method ordering

Please let me know if you have other ideas, too.

16 comments

On 2003/11/12 20:27, Dave Kriewall wrote:

Please let me know if you have other ideas, too.


- Rearranging a selection

Sometimes you can't rearrange an entire file because some field depends
on order of initialization. Rearranging the file would break the code.
In that case I would like to be able to select part of the file to
rearrange.

Thanks for your great plugin!
Bas

0

Dave,

You made it. Congratulations.



Problem 1:
-



The "Class Member Order" dialog is too tall, and is not resizable : I
can't access the bottom OK/Cancel buttons.
That's how I ran into the next problem :


Problem 2:
-


NPE, when closing the "Class Member Order" dialog, by clicking on the
upper right symbol.

Error message: Error during dispatching of
java.awt.event.MouseEvent[MOUSE_RELEASED,(942,84),button=1,modifiers=Button1,clickCount=1]
on dialog0
java.lang.NullPointerException
at
com.wrq.rearranger.configuration.SettingsPane$2.actionPerformed(SettingsPane.java:149)



Request 1 : adding spaces, and comments on arranged extracted methods.
-


Now that we can group and sort methods according to the logical calling
flow, it would be nice to make the grouping more visually obvious,
through optionaly
- adding blank lines and/or comments, before and/or after the father method
- adding blank lines and/or comments, before and/or after the children
methods


Request 2 : in tab 1 and 2, add a quick way to fill by default.
-


The 2 lists are empty, in the first 2 tabs. If they were prefilled, it
would be less impressive than the current "white page", and we could
quickly get a working solution by slightly modify/reordering the default
suggestion.

Suggestion 1 : add a simple "prefill: button.
Suggestion 2 : add a button to : "prefill based on current class."

Another implementation would be to offer a , in each tab,
and pack a few hardcoded default profiles with the plugin.


Alain






0

Dave ,

>Please let me know if you have other ideas, too.

>

I do, actually :)

-


Request 1:
-



After reordering "extracted methods",
it would be nice if the rearranger would display in a popup a quick
summary of the call workflow it discovered, while doing its job.

version 1 : plain text very simple display, like :
-





*1 : fooBody is called by both father methods.
=> display it in another colour.


version 2 : drawn display
-



version 3 : like display
-



(At this stage, you wouldn't be far from implementing your very own and
improved .)


If this feature were available, I think I would do dummy Rearranging,
just to see the summary.
This leads naturally to the 2nd request :



-


Request 2 :
-



Provide the feature above as a standalone action (that can be called
separately/directly )

It would nicely complement , and I even might turn to use it
more frequently than


What do you think?


Alain


0

Hi Alain,

You are very creative! I think it's a good idea. Essentially I would show the "tree" as it would be rearranged. I could just implement a JTree with parent/child indicating caller/callee relationship. Methods called by more than one parent can be in a different color, maybe with a mouseover tooltip that says how many or who the parents are.

Depending on the keystroke perhaps that started it, the rearranger might only display this tree, or might display the tree and then finish the rearrangement if you OK it. So you could have the dummy Ctrl-F12 and the rearranger would only analyze and display, not do any actual work.

Does that sound like what you want?

(I never thought I'd have a color chooser dialog for the rearranger, but now you'll probably want it so you can pick the color for methods called by more than one parent. :)
-Dave

0

Dave,

>I could just implement a JTree with parent/child indicating caller/callee relationship.
>


I fear - booo - that a JTree would waste space, and be not very readable
: look at the new "improved" design of the Code Inspection Result display!

version 1a :
That's why I suggested plain text as a first version: easy to create and
easy to display.

version 1b :
A tad less simple : write the result into html, and display it in a
JEditorPane
Through a Velocity template, you could even let use customize the result
themself :)

version 2a :
For readability, the ideal solution would be a actual drawing, with thin
lines (and arrows ?) to translate the workflow.

version 2b :
For usability, if you want to allow scroll_to_source, on ,
like the does, then I guess a tree would be an easier option.

It's up to you. I'd put readability first.
I think
- a plain text result would already be very good.
- html would let you add colour easily.
- customizable Velocity templates would be great.

Alain

0

Dave,

Is there any way currently to specify that you'd like the getter and
setter for a given property to be placed together? I can't seem to find
it; alphabetize puts all the gets together and all the sets. Maybe you
could modify the sort for getters/setters to only sort based on property
name?

Cheers,
N.

Dave Kriewall wrote:

Please let me know if you have other ideas, too.


0

Hi Nathan,

You're right, there's no such setting! It's an oversight on my part, we (plugin group) discussed it earlier. I forgot to do it.

So I'd add a checkbox named "Keep related getter/setter together", and if alphabetizing, do so based on the property name. (Or should it be getter method name**?) Setter would follow immediately. Default setting would be checked.

(** JTOL (just thinking out loud :)-- If you made a method rule "all methods," and I alphabetized on property name, then the g/s'ers would be paired but scattered throughout the remaining methods. If alphabetizing on getter method name, then at least all the g/s'ers would be grouped together. (Well, the "get"s together and the "is"s together.) What to alphabetize by (property name or getter method name) could be an option. Of course, if you made a method rule "getter/setter methods" this wouldn't be an issue. OK, I'll propose just alphabetizing on property name.)

I suppose this is a global setting; can't imagine what it would mean to change the value of the setting for different method "rules." (It definitely doesn't belong on the new "Extracted Methods" pane since G/S'ers are specifically excluded from consideration as extracted methods.)

Does that sound sufficient? I'll assume it is unless there are replies to the contrary.

-Dave

0

Sounds a pretty comprehensive solution to me!

Cheers!
N.

Dave Kriewall wrote:

Hi Nathan,

You're right, there's no such setting! It's an oversight on my part, we (plugin group) discussed it earlier. I forgot to do it.

So I'd add a checkbox named "Keep related getter/setter together", and if alphabetizing, do so based on the property name. (Or should it be getter method name**?) Setter would follow immediately. Default setting would be checked.

(** JTOL (just thinking out loud :)-- If you made a method rule "all methods," and I alphabetized on property name, then the g/s'ers would be paired but scattered throughout the remaining methods. If alphabetizing on getter method name, then at least all the g/s'ers would be grouped together. (Well, the "get"s together and the "is"s together.) What to alphabetize by (property name or getter method name) could be an option. Of course, if you made a method rule "getter/setter methods" this wouldn't be an issue. OK, I'll propose just alphabetizing on property name.)

I suppose this is a global setting; can't imagine what it would mean to change the value of the setting for different method "rules." (It definitely doesn't belong on the new "Extracted Methods" pane since G/S'ers are specifically excluded from consideration as extracted methods.)

Does that sound sufficient? I'll assume it is unless there are replies to the contrary.

-Dave


0

Alain,

I must be looking at the wrong thing in Code Inspection -- the resulting tree seemed pretty compact, and I don't recall it looking any different in the past. Sorry, I'm missing your point.

But I was thinking of allowing and ]]> from the popup to allow quick navigation to the item.

Do you think the tree on File Structure pane (not popup) wastes space or isn't readable? I would expect mine to be similar.

0

Dave

>.. in Code Inspection -- the resulting tree seemed pretty compact
>

It is, but you have very few possibilities to tune the design : a JTree
is a JTree..
When it comes to displaying vital info, for a very frequent use, I want
it lean and clean, with the minimum noise, and tuned to the pixel for
perfect readability.
I want to grab most of the information just by Seeing. Looking comes
after. I don't want to have to search, or unfold branches.
I'm not sure you could reach that with a JTree, but I could easily be
wrong.

On the other side, a tree makes navigation easier to implement.

I thought you would jump on the ASCII / html suggestion wagon, because
it would have made your life easier. Apparently, I'm lazier than you
are. Or you're better at Swing than I am. Or both. :).

Alain

0

Well, I'll give it a try with the JTree (after some other features are implemented, that is). I can expand all the nodes, in fact can keep them from being collapsible. And it makes it easy to figure out what item is being clicked. I think a lot depends on the properties I inherit from IDEA. I'm hopeful it will look nice.

If you don't like the result, I'm sure we can work something else out. :)

-Dave

PS. "Nobody is lazier than I am. I work hard at it."

0


request : 2 (?1) option(s) to insert a blank line between "families"
-


option 1: add a blank line between "family".
option 2: add no blank line when family is 1 person.


1/
When I "CollapseAll", the "flattenize" option of the CamouflagePlugin
makes all methods flat (use 1! line).
Adding a blank line would make the call flow clearer.

2/
If there is no child, I'd like an option to have the 1-person families
stick together :


Example: after (What I want to obtain)



Alain

0

Thanks for the suggestions. I was about to start work on it, just to get a break from the perplexing tabifier. :)

I'm not quite sure what you mean by option 1. Is it that you want the ability to add a blank line between all top-level groups? I.e., to use our past examples, between a (grandfather and all children) and the next (grandfather and all children). Or does option 1 mean a blank wherever the nesting level changes?

Perhaps you could supply a small example. Either way, I think my design (described below) will satisfy you.

I understand your option 2 from the example you gave. Formally, it looks like you want the ability to emit a blank line when:
(a) going up one or more levels (between child3 and father2); or
(b) going to a sibling who has children (between father3 and 4)

I was going to handle blank lines as part of the comment block. Essentially you construct a "comment" that contains however many blank lines or Java comments you want.

And I was thinking of making comments available at:
(1) top level (before and/or after)
(2) at level change (before and/or after)
(3) at "family" change (your option #2) (before and/or after)

I would make the top level method name available via a keyword expansion for any comment.

Does this sound satisfactory?

Thanks,
-Dave

0

Dave Kriewall wrote:

>Does this sound satisfactory?

>

Yep, it sound good. Can't wait to try it out :)

Alain

0

Bug: Extracted methods are not detected when they appear in an inner class.
-



Example :
-


private static void ChildA ( final CaretEvent i_caretEvent )
{
}

public static void Father ( final Editor i_justCreatedEditor )
{
i_justCreatedEditor.getCaretModel().addCaretListener(new
CaretListener(){
public void caretPositionChanged ( final CaretEvent
i_caretEvent ) {
childA ( i_caretEvent );
}
});
}

Problem:
-


the 2 methods above will not be rearranged,as the plugin doesn't see the
call to ChildA, in the inner class.

0

Thanks, Alain -- that shouldn't be too hard to fix.

The new does-it-all rearranger is making good progress. Hope to have something in a couple of days.
-Dave

0

Please sign in to leave a comment.