The rearranger plugin
The plugin performs two basic automatic rearrangement tasks:
- reordering the outer classes in a Java file, and
- reordering the fields, methods, and inner classes within an outer class.
Rearrangement is based on configuration supplied by the user, on the relationship between methods based on method calls, or both.
A default configuration is supplied and is loaded the first time the plugin is seen. If the configuration is empty, no rearrangement takes place.
The user may create a list of entries, specifying various attributes of the fields, methods, and classes. These attributes include all the standard Java modifiers (public, private, protected, final, static, etc.) as well as some other criteria (e.g., method is constructor, getter/setter).
The list may also contain comment entries. Comments may be conditionally inserted before or after reordered groups.
Extracted (related) methods may be grouped with their callers. An extracted method is one which is called by another method.
Getters and setters may be kept adjacent, as well as overloaded methods (including constructors).
Finally, the number of blank lines appearing before or after certain braces may be specified.
The Rearranger only works with IDEA versions 4.0 and above. (If you are on a non-Windows platform, ensure that IDEA is running with Java 1.5 or later.)
Use IDEA's Plugin Manager to install the Rearranger plugin. (Installing any plug-in with IntelliJ, including the Rearranger, is a snap. You don't have to download or build anything. In IntelliJ, click File | Settings | IDE Setting | Plug-ins. You can then view the plug-ins installed already and what is available. Right click "Rearranger", and select install. (Selecting and hitting OK does nothing).)
To configure, go to "Settings...IDE Settings...Rearranger" configuration dialog.
To automatically rearrange a file, first edit the desired Java file, then choose Edit...Rearranger (or Ctrl-Alt-Shift-R, the default shortcut). (Alternatively, if the Reformat plugin is installed, the Rearranger will run automatically after Reformat finishes.)
If the Preview Rearrangement option is checked, a dialog displaying a tree of the proposed rearrangement appears, which the user can accept or reject.
To manually rearrange a file, edit the desired Java file, then choose Edit...Live Rearranger (or Ctrl-comma, the default shortcut).
A description of the plugin's operation can be found here.
There are six basic areas of configuration:
To control the order of outer classes or class contents, you create a list of rules which describe class or class member attributes. Choose one (or both) of the first two configuration tabs:
- "Class Member Order" controls the order of fields, methods and inner classes within a class;
- "Outer Class Order" controls the order of top level classes in the Java file.
This is a sample of what the "Class Member Order" pane might look like:
On each of the first two tabs, you can add, edit, duplicate, or remove rules, or move them up and down in the list.
All items (outer classes, fields, methods, and inner classes) may be selected on the basis of their type, and presence or absence of other attributes such as protection level, final, or static attributes. Only fields match a rule whose type is "field," and so on.
All items may be selected by matching their names to a regular expression pattern.
If no protection level is specified in a rule, then protection level is ignored when matching.
Additional attributes exist where appropriate for individual rule types.
The rule types for "Class Member Order" rules are:
The rule types for "Outer Class Order" rules are:
In all cases except comments, a number of attributes may be specified. Classes or class members are then rearranged in order of the rules whose attributes they match.
The order in which rules are specified (sequence order) dictates the order in which rearranged items will appear in the resulting file. Rule priority controls the order in which rule items are matched. By default, all rules have a priority of 1 (the lowest). The priority can be changed by double clicking on the "Priority" field of the desired row. Clicking on the "Seq" (sequence) or "Pri" (priority) column headers will sort the table; sequence numbers are sorted in ascending order, priority in descending order. This order can be reversed by shift-clicking on the column header.
An example of the usefulness of rule priority is when a method is matched by name. Suppose that you want all methods, then all fields, then any methods whose name is "main". Without rule priority, you would have to specify the following rules:
- All methods whose name does not match "main"
- All fields
- All methods whose name matches "main"
Assigning a higher priority to rule 3 would eliminate the need to specify the "name does not match" clause in rule 1.
The "Field" rule arranges fields with matching attributes together.
The field attributes dialog is as follows:
Fields may be selected on the basis of protection level, static, final, transient, and volatile attributes. Fields may be selected if they are initialized to an instance of an anonymous class. Fields may also be selected on the basis of matching their type to a regular expression.
If any sort options are checked, fields matching the rule will be rearranged according to the options. Otherwise, fields retain their original relative order.
Fields may be alphabetized by modifiers (e.g. "public final"), by type, and/or by name, grouping fields of the same type together. The type and name alphabetization can be case insensitive, so that (for example) primitive types like "int" would appear between "Boolean" and "String".
The method attributes dialog is as follows:
Methods may be selected by their category (constructor, getter/setter, canonical, or other). A canonical method is one that is inherited from java.lang.Object.
If no method category is specified, the method category criterion is not applied.
The implemented/-ing and overridden/-ing criteria are defined as follows:
- "implementing" means the method implements an abstract or interface method
- "implemented" means the abstract or interface method is implemented elsewhere
- "overriding" means the method overrides a concrete supermethod
- "overridden" means the concrete method is overridden elsewhere
Methods may be selected based on whether their return type matches a regular expression or not.
Methods may be selected based on a minimum and/or maximum number of parameters.
If "Exclude from extracted method processing" is checked, methods matching this method rule will be moved, but their related (extracted) methods won't. This permits those (otherwise extracted) methods to match rules of their own. For example, checking this box on a rule "All constructor methods" would arrange all constructors together, but would not arrange any called methods with them.
Methods may be sorted by modifiers (e.g., "synchronized"), by return type, or by name.
When a method rule is created, the default definition specified in General Options pane for getter/setter is copied. This definition may be changed per rule by clicking on the "getter/setter" button in the method type selection box. Doing so brings up the following dialog:
Refer to General Options for more information.
An interface methods rule causes methods which implement one or more interfaces to be grouped together. Unless otherwise specified (by name matching criterion), all interfaces match this rule, and all methods implementing an interface method will be moved. Methods belonging to one interface are never intermixed with those of another.
The interface methods attributes dialog is as follows:
If "Alphabetize Interfaces" is checked, then interface method groups are arranged in alphabetical order based on the interface name. Otherwise, interfaces are arranged in the order their first implementing method is encountered.
Leading and trailing comments may be specified for each interface method group. These comments serve to delimit methods of a particular interface. Any occurrence of "%IF%" in the comment will be replaced by the interface name. See Global Comment Pattern for related information.
The inner class attribute dialog is as follows (the outer class dialog is similar):
If "enum" is checked, then only classes which are enumerations (keyword "enum") will match the rule.
Classes may be sorted by modifiers (e.g. "public abstract"), type (class or enum), and/or name.
The comment attribute dialog is as follows:
Before rearranging, the file is scanned for any existing comments that match the comments or the global comment pattern specified by the user; if any are found, they are removed (on the assumption that they were generated by the plugin during a previous rearrangement). Adjacent blank lines are also removed, so that the final result will contain only those blank lines specified in the separator comment definition.
Then, as rules are executed, comments are inserted as they are encountered in the list if certain criteria are met. A comment may be emitted:
- unconditionally
- only if items match any or all of the preceding rules
- only if items match any or all of the subsequent rules
- based on both (previous and subsequent) conditions
For example, if your Class Member Order rules are defined as follows:
- Comment (// FIELDS BEGIN HERE) when any of subsequent 2 rules are matched
- Comment (// PRIVATE FIELDS BEGIN HERE) when subsequent rule is matched
- private fields
- Comment (// PRIVATE FIELDS END HERE) when preceding rule is matched
- Comment (// STATIC FIELDS BEGIN HERE) when subsequent rule is matched
- static fields
- Comment (// STATIC FIELDS END HERE) when preceding rule is matched
- Comment (// FIELDS END HERE) when any of preceding 2 rules are matched
then the "PRIVATE FIELDS" comments will only appear if one or more private fields were found; likewise, the "STATIC FIELDS" comments will only appear if one or more static fields were found. The "FIELDS BEGIN/END HERE" comments will only appear if at least one private or static field was found.
Blank lines may appear before and/or after the comment; simply insert them in the comment definition.
A "fill string" capability allows comments to be dynamically adjusted to a specified width. By default, the width is the project's right margin but may be overridden. All occurrences of "%FS%" in each line of the comment are replaced by an equal number of characters from the fill string, causing the comment to expand to the desired width. Comments may therefore be left or right justified, or centered. For example,
// Left-Justified Comment %FS%
// %FS% Right-Justified Comment
// %FS% Centered Comment %FS%
The "Extracted Methods" tab controls the grouping and ordering of calling and called methods. It will arrange called methods underneath calling methods in a variety of ways. Comments can be generated to delineate top level groups, every method, every level, or every family of methods.
The extracted method dialog contains two panes:
The first pane controls grouping, as follows:
The first checkbox, "Move extracted methods," controls whether or not extracted methods will be moved under their callers. If checked, all other controls on the dialog are enabled. If unchecked, all calling-based relationships between methods are ignored. (Overloaded and related getter/setter methods are handled separately; these are name-based or function-based relationships.)
If called by more than one method, an extracted method may be placed under the first or last caller by choosing "below first usage" or "below last usage."
When nested calls are made, so that an extracted method is a caller of other extracted methods, the extracted methods may be arranged in depth-first or breadth-first order.
The order of the extracted methods under a parent may be:
- order of invocation (usage order of appearance)
- original order (relative to position before rearrangement)
- alphabetical
All private methods are considered extracted methods. No getters or setters are considered extracted methods. However, there may be ambiguity about remaining (non-private, non-getter/setter) methods. A rule exists to control whether to consider these methods as extracted methods:
- never
- only if called by exactly one other method (which could invoke it multiple times)
- when it has one or more callers in the class.
The other pane specifies where comments should be generated, as follows:
Comments may be placed before and/or after groups of extracted methods. The first box specifies where comments should be placed:
- Top Level: comments will be placed before the first (top-level) calling method, and after the last extracted method in the tree.
- Each Method: comments will be generated before and after each method in the tree.
- Each Level: comments will be generated before and after each level change recursively; i.e., in a breadth-first traversal, level 1 ends after level 2 ends, not before.
- Each Family: comments will be generated to group all siblings (except before the first) who have no children. Siblings with children start a new "family."
These comments may also utilize the fill string feature.
The "General" tab allows you to specify several options:
A detailed description of each option follows.
Setting this option will cause setters to appear immediately below getters, wherever the rearrangement may place them. If sorted by name, the property name will be used (not the getter method name).
Setting this option causes getters and setters to appear immediately below their associated property (field) declaration.
This option is only enabled if Keep Getters/Setters Together is enabled.
Setting this option groups overloaded methods (those with identical function names, but different parameter types or number of parameters) together. These overloaded methods, including constructors, may be sorted by number of parameters (ascending or descending), or kept in original order.
Setting this option will cause a popup (similar to the Ctrl-F12 file structure popup) to appear before rearrangement takes place. This popup contains a tree showing the order and hierarchical arrangement of classes and class members, including the nesting order of extracted methods. OK this to proceed with rearrangement, or Cancel to stop.
The following illustration shows the confirmation dialog, configured to display all fields, parameter types and names in method declarations, and all rules.
This can aid in debugging the rearranger configuration, as it shows exactly what rule every item matches.
The dialog can be significantly simplified by restricting the rules to only those with matches, or by not displaying rules at all:
The buttons to control the format and content of the tree are:
 controls whether or not parameter types are displayed in method declarations.
 controls whether or not parameter names are displayed in method declarations.
 controls whether or not fields are displayed in the proposed rearrangement tree.
 controls whether the method type appears after or before the method name.
 controls whether or not comments (and comment rules, if Show Rules is selected) will appear in the proposed rearrangement tree.
 controls whether or not rules will appear within the rearrangement tree. If selected, all rules appear in the tree (in italicized text) and all matches to those rules appear beneath the rule's node. Otherwise, only the classes and class members appear.
 Restricts the display to only those rules with matches. This eliminates clutter in the display.
If checked, contents of inner classes will be rearranged recursively. If not, contents of inner classes are copied intact to the resulting file.
This definition specifies the default criteria for determining if a given method is a getter or setter. Criteria are based on the method name and body. A getter method name must begin with a valid prefix ("get", "is", "has"); it may also be required to have a field name which is returned by the method. A getter body may be ignored, required to have a return statement, or required to have a return statement followed by the field name specified in the method name. A setter method name must begin with "set"; it may also be required to have a field name which is assigned by the method. A setter body may be ignored or be required to have one assignment statement which assigns the parameter value to the field name.
This definition will be copied by any method rules created afterward.
A method rule may override the definition. If a method does not match any rule, the default definition is used to determine if it is a getter or setter.
The comment pattern is a regular expression to which all your fixed comments should conform. The Rearranger will remove any comments matching this pattern before it does the rearrangement. This prevents duplicated comments from being generated every time a file is rearranged. This also allows you to make minor changes to your fixed comments and have the Rearranger locate and remove the old ones.
- "Generate Pattern" creates a regular expression that will match all user-specified comments, including comment rules and extracted method comments.
- "Verify Comments Against Pattern" checks to see that all your fixed comments match the pattern supplied. A dialog box will display any that do not.
TIP: all comments specified in separator comment rules are automatically removed from the file before rearranging. The global comment pattern is really only useful if you need to remove old comments of a different style. Suppose you are changing from dashes to periods ( // --- comment --- becomes // ... comment ... ). Then specifying a global comment pattern of // -+ [a-zA-Z0-9] -+ would remove all the old comments. In addition, any blank lines adjacent to these old comments will be stripped. (It is probably easier just to use the Edit...Replace feature with a regular expression.)
The number of blank lines at certain locations may be forced. These locations are:
- After class opening brace
- Before class closing brace
- After class closing brace
- Before method opening brace
- After method opening brace
- Before method closing brace
- After method closing brace
In addition, an option to remove any leading or trailing blank lines within a code block is provided.
Precedence is in the order just given, top to bottom. Therefore, if you force no blank lines after a method closing brace but force 2 blank lines before a class closing brace, then there will be 2 blank lines between the last method of a class and its closing brace.
All blank lines will be stripped from the end of a file; this overrides the "After class closing brace" setting, which could leave blank lines after the last outer class in the file.
This dialog permits the user to:
- Clear the configuration; all rules are discarded and default settings installed.
- Load the default configuration. This is stored as a resource (DefaultConfiguration?.xml) in the plugin's .jar file.
- Read configuration from a file.
- Write configuration to a file.
The plugin supports a manual mode for rearrangement, in which a popup dialog is displayed showing all the items (classes, fields, methods, etc.) in the file. The user can drag and drop items in the dialog to the desired order.
The live rearrangement function can be invoked by the Edit...Live Rearranger menu item or with the default keystroke Ctrl-comma. Any keystroke or mouse click outside the popup window will dismiss the popup.
First, the plugin parses the file, creating a tree of classes and their contents.
Next, the plugin takes each rule in order of highest priority, and (within priority) sequence order. It creates a list of items matching each rule. Items in this list are either in order encountered, or alphabetized if indicated in the rule.
If configuration indicates that extracted methods should be grouped with their callers, and if the rule does not override the global option, these methods also will be moved.
If "Confirm before rearranging" is checked, a dialog is displayed showing the proposed rearrangement.
If the proposed rearrangement is accepted, the plugin generates a new file, emitting items in sequence order of the rules they match. The plugin conditionally generates comments as it encounters these in the rule list, as described above.
Anything that does not match a rule will appear at the end of the Java file (if ordering classes) or end of the class definition (if ordering class members). For example, creating a class member order list of only "public static void fields" will move all of those to the front of the class; anything that might have been before or between these fields will appear immediately after them.
- Download the .jar file (see below) into your IDEA/plugins directory, or use IDEA's Plugin Manager to do it automatically.
- Restart IDEA.
| Plugin Author: | DaveKriewall |
| Current Plugin Version: | 14 Feb 2007 (4.7) |
| Change History: | |
| 14 Feb 2007 (version 4.7): | 1) Fix String-related exception when rearranging a file containing a "set()" method with one parameter.
2) Calculate apparent width of leading tabs in comment strings properly.
Thanks to Hans Haggstrom and Thomas Singer for the bug reports. |
| 26 Nov 2006 (version 4.6): | 1) Fixed some problems with implicit modifiers for constants and methods of an interface. All interface constants are regarded as public static final (whether explicitly indicated with modifiers or not). Likewise, all interface methods are regarded as public.
2) Fixed situation where getters and setters are grouped together, but both a getter and a setter matched a rule for "methods implementing interface". Result was that the setter was incorrectly emitted twice. Now, if the rule "Keep Getters/Setters Together" is enabled, it takes priority over all other rule matching. In particular, in such a circumstance the setter will be excluded from other rule matching possibilities.
Thanks to Sebastian Graca for pointing out the bugs. |
| 24 Jul 2006 (version 4.5): | 1) Fixed sorting of overloaded methods; now methods with identical numbers of methods remain in their original order. (Bug was that their order was inverted each time the plugin ran.)
2) Fixed problem parsing generics ("<E extends Object>") syntax.
Thanks to Sebastian Graca for pointing out the bugs and supplying fixes. |
| 13 Jul 2006 (version 4.4): | 1) Improve detection of canonical methods (regardless of whether JDK is specified).
2) Simplified appearance of rule specification dialogs.
3) Added ability to select enum classes in class rules. (Allows grouping enums with fields, for example.)
4) Fixed UI problem where static and abstract attribute checkboxes overlapped in inner class rule dialog.
5) Added ability to sort fields, methods and classes by modifiers, by type, and/or by name. Type and name may be designated case insensitive. (Modifiers are all lower case anyway.)
6) Modified default configuration to include a new comment ("// --- ENUMERATIONS ---") and a rule to match enumerations. This effectively separates enumerations from other inner classes which continue to match another explicit rule in the default configuration. |
| 30 Oct 2005 (version 4.3): | 1) Fixed corruption of Java file header region (package statement, import statement, or comments) when respacing options were enabled and document had no trailing blank line.
2) Fixed possible corruption of Java file (typically deletion of left or right brace for a method or class) when respacing options conflicted.
3) Clarified rule "Methods implementing interfaces"; now include generated comment in rule description. |
| 28 Oct 2005 (version 4.2): | 1) Handle additional formatting possibilities for enum classes; now no longer generates duplicate text. |
| 25 Oct 2005 (version 4.1): | 1) Minor change necessary for IDEA 5.0 (Irida build 3431) in which supplied XMLOutputter class changed.
2) Fixed ArrayIndexOutOfBounds? exception that occurred when parsing an enum without a final semicolon after the last field.
3) Fixed problem where methods were dropped during rearrangement when "Keep Extracted Methods Together" was chosen and the method call tree was circular; e.g. if method1 calls method2, and method2 calls method1, then neither would appear if the option was chosen. Now circular references are eliminated and the first method encountered during rearrangement will precede the other in the rearranged output.
4) Show enums in popup tree with "enum" icon, not "class" icon. |
| 26 Mar 2005 (version 4.0): | (1) Fixed bug: Adding a rule when none was previously selected caused an ArrayIndexOutOfBounds? exception.
(2) Cancelling an edit no longer acts as if OK were pressed.
(3) Interface method rule now allows comment fill string capability.
(4) Preview ("Confirm before rearranging") shows expanded comments (with "fill string" operation performed.) |
| 23 Feb 2005 (version 3.9): | (1) Added ability to select methods based on number of parameters.
(2) Enhanced rule dialogs to permit selection of multiple rules (for moving and deleting).
(3) Added "fill string" capability to generated comments, automatically widening them to the project's right margin or a specified width. Depending on the use of the fill string keyword %FS%, comments may be left or right justified, or centered. |
| 28 Jan 2005 (version 3.8): | (1) Added ability to arrange getters and setters immediately below their respective property (field) declarations.
(2) Fixed bug with Live Rearranger when Show Fields was turned off. |
| 26 Jan 2005 (version 3.7): | (1) Fixed problem (NPE or introduction of syntax errors) when Rearranger applied spacing rules to source containing multiple braces on the same line.
(2) Should handle Java 5.0 "enum" syntax. |
| 24 May 2004 (version 3.6): | (1) Fixed bug; if "Rearrange contents of inner classes" is not checked, don't generate any comments; just leave the inner class alone.
(2) Updated for newest version 0.7.1 of Reformat plugin. |
| 19 Apr 2004 (version 3.5): | (1) Fixed rule matching for implemented/implementing/overridden/overriding method attributes.
2) Horizontal and vertical scroll bars in the Live Rearranger dialog are no longer focusable. Focus goes from tree to OK to Cancel button and back to tree.
3) Added a new spacing control to "Force <N> blank lines before method open brace".
4) When using Ctrl-Shift-(Up,Down)Arrow to move items in the Live Rearranger, keep the item being moved visible by scrolling appropriately when it reaches the top or bottom edge.
5) Made some changes to allow project to compile under Pallada. No longer able to use PsiJavaToken? constants.. |
| 15 Apr 2004 (version 3.4): | Fixed display of icons in dialogs.
Enter key (as well as Ctrl-Enter) dismiss Live Rearranger dialog and perform rearrangement. |
| 13 Apr 2004 (version 3.3): | Distinguish between overrides and implements attributes for methods. Show overrides /implements / overriding / implementing icons in confirmation and live rearranger dialogs. |
| 05 Apr 2004 (version 3.1): | Added ability to sort fields alphabetically by type as well as by name. Type comparison may be case insensitive. |
| 03 Apr 2004 (version 3.0): | (1) Live Rearranger now shows focus changes between tree and buttons. Focus starts in the tree.
(2) First blank line of a method is no longer discarded when a generated comment precedes the method. |
| 01 Apr 2004 (version 2.9): | The Live Rearranger feature was enhanced as follows:
(1) allows selection of multiple (discontiguous) rows.
(2) added keyboard control for rearranging (using ctrl-shift-{up arrow, down arrow} key combination.)
(3) Drag and drop of a contiguous selection is also possible by clicking the first row, shift clicking (and holding) the last row, releasing shift key and then dragging.
(4) Keyboard accelerators were added for all icon buttons.
These bugs were fixed:
(1) Live Rearranger dialog now shows all getters and setters.
(2) Ignore leading spaces when scanning for and removing pre-existing comments.
(3) Handle empty comments properly.
(4) Method body no longer scanned for comments.
(5) Preserve multiple spaces in comments when saved to and loaded from configuration file. |
| 26 Mar 2004 (version 2.8): | (1) Live Rearranger dialog now expands the tree automatically.
(2) Toggling options on the Live Rearranger won't collapse the tree.
(3) Live Rearranger now shows inner class contents.
(4) Live Rearranger now shows class initializers in the tree; their omission was causing items to be dropped to the wrong location.
(5) Spacing control added to specify the number of newline characters at end of file. Default is 1 (terminates the final line with a newline character.) This gives the appearance in IDEA's editor that a blank line exists at the end of file, but there really isn't any. |
| 24 Mar 2004 (version 2.7): | (1) Fixed spacing problems with inner classes.
(2) Fixed spacing problems encountered in files with trailing whitespace on lines.
(3) If there are more than two getter/setters for a given property, bring all together, and don't duplicate the setter. |
| 18 Mar 2004 (version 2.6): | (1) Added ability to rearrange directory contents (recursively) from Project pane.
(2) Display more detailed icons in popup trees; show static and protection level attributes. |
| 12 Mar 2004 (version 2.5): | (1) Changed Live Rearranger from popup to resizable dialog (may avoid threading issues that hung IDEA).
(2) Added insertion hint when dragging items in Live Rearranger. Thanks to Vilya Harvey for the sample code.
(3) Fixed some autoscrolling bugs.
(4) Used nifty new Rearranger icon, designed by Alexey Efimov. |
| 11 Mar 2004 (version 2.4): | fixed bug in determining if a method is canonical or interface. Thanks to Nic Holbrook for the fix. |
| 11 Mar 2004 (version 2.3): | fixed problems with icon button display due to case mismatches in both automatic (confirmation) and manual rearrangement popups. |
| 08 Mar 2004 (Version 2.2): | Bug fixes:
(1) Repeated Rearranging no longer inserts an additional blank line after a generated separator comment.
(2) Inner class separator comments are properly removed and regenerated.
(3) Toolbar icons in Live Rearrange popup might be fixed. (I am guessing that they worked on Windows platforms but not Linux because of upper/lowercase issues)
(4) Blank lines before and/or after separator comments are now preserved and correctly inserted.
(5) Default configuration updated to add a blank line before and after each separator comment.
(6)Confirm Rearrangement dialog has been enhanced in a few ways.
(6a) Separator comments may optionally be shown in the tree, both as rules and as generated comments.
(6b) The list of rules shown may be restricted to only those with matching items.
(6c) And the checkboxes have been replaced with buttons.
(7) Option added to rearrange inner class contents (or not). |
| 25 Feb 2004 (Version 2.1): | Added default configuration, and ability to save and restore configurations to file.
Added Live Rearranger feature.
Bug fixes:
(1) "force lines" spacing options now properly saved and restored. You should recheck your settings.
(2) Force Spacing logic improved to handle nested anonymous classes. Special cases provided for last method of class (ignore "Force Spacing After Method Close Brace") and for last class in file (place one newline character after the final brace.)
(3) Fixed exception in spacing logic. Thanks to Bas Leijdekkers for the report. |
| 06 Feb 2004 (Version 2.0): | Fixed bug parsing a trailing "// comment" after a field declaration; could cause infinite loop.
Fixed global pattern generation bug.
Fixed spacing bug where nested code block contained an anonymous class.
Improved checking for read-only files (thanks to Jacques Morel for the code sample). |
| 03 Feb 2004 (Version 1.9): | Added global comment automatic generation capability.
Added 'Duplicate' button to rule tables, and support for up/down arrows, enter key; double clicking a row edits that row.
Fixed class cast exception when class initializer was present.
Fixed handling of read-only files. |
| 28 Jan 2004 (Version 1.8): | Added rule priority feature.
Added "interface method" rule, to group methods implementing an interface together.
Several bug fixes. |
| 09 Jan 2004 (Version 1.7): | Added ability to exclude certain methods from "extracted-method" analysis and processing. (Methods matching a method rule so marked will be moved, but their extracted methods won't.)
Added new method type "canonical", in addition to existing method types "constructor", "getter/setter" and "other". (Canonical methods are those inherited from java.lang.Object, e.g. equals(), hashCode(), toString().)
Made definition of getter and setter methods more flexible; each rule can specify its own definition to override a default global definition.
Fixed method rule "and [not] overriding" attribute. |
| 10 Dec 2003 (Version 1.6): | Added options to force N number of blank lines before/after method/class open/close braces, and to remove leading and trailing blank lines inside a code block. |
| 03 Dec 2003 (Version 1.5): | Add "show fields" checkbox to file structure popup.
Fix multiple field declaration parsing problem: "int b, a;" will no longer be incorrectly separated (",b; int a") if alphabetical sorting was specified.
Attempting to rearrange an XML file no longer causes IDEA to hang. |
| 01 Dec 2003 (Version 1.4): | Fix parameter display in file structure popup, and provide choice of parameter type and/or name display. |
| 27 Nov 2003 (Version 1.3): | Added several features and fixed a number of bugs.
General Settings pane added to control:
(1) Keep Getters/Setters together;
(2) optionally sort overloaded methods by number of parameters;
(3) show rearranged file structure popup;
(4) provide global comment pattern, and provide ability to check existing comments against the pattern.
(5) New subpane allows extracted method comment generation.
Bug fixes:
(1) Close box for Attribute selection dialogs no longer generates NPE;
(2) all attribute selection dialogs laid out to make better use of space;
(3) method calls made in an inner class are now entered into the call graph for determination of extracted methods;
(4) bug fix to avoid exception or hanging when no outer classes exist in the file (e.g. XML files). |
| 12 Nov 2003 (Version 1.2): | Add logic to move extracted methods underneath calling methods.
Fix bug which could hang IDEA. |
| 06 Nov 2003 (Version 1.0): | Fix deletion of previously inserted comments configured with trailing spaces.
Trailing spaces are truncated in Java file, so string comparison for comments was failing. |
| 05 Nov 2003 (Version 0.9): | Add multi-rule comment emission logic.
Fix deletion of comments inserted by a previous run of the Rearranger when those comments were adjacent. |
| 04 Nov 2003 (Version 0.8): | fixed bugs:
(1) eliminate writeAction() exception;
(2) persist Match Name data correctly when name is empty |
| 03 Nov 2003 (Version 0.7): | fixed bug: some configuration options were not being saved or restored |
| 28 Oct 2003 (Version 0.6): | detect anonymous inner class initializer for items;
add ability to match item name to a regular expression pattern;
fix configuration panel so that settings change is detected properly;
fix problem with detecting methods marked as "getter/setter or other";
add ability to match class static initializer;
add ability to conditionally emit comments between rules;
added native, synchronized, transient, and volatile attribute support |
| 20 Oct 2003 (Version 0.5): | add alphabetical sort capability;
fix move up/down buttons |
| 17 Oct 2003 (Version 0.4): | fixed problem with static & final field detection |
| 16 Oct 2003 (Version 0.3): | add support for Reformat plugin chaining;
fixed "method is overridden" detection |
| 15 Oct 2003 (Version 0.2): | fix ClassCastException? when editing a configuration entry. |
| 14 Oct 2003 (Version 0.1): | Initial version |
| Jar Dependencies: | none, but may be invoked by Reformat plugin |
| Plugin Home: | http://www.intellij.org/twiki/bin/view/Main/RearrangerPlugin |
| Feedback: | http://www.intellij.org/twiki/bin/view/Main/RearrangerPluginDev |
Related Topics: ReformatPlugin, TabifierPlugin
-- DaveKriewall - 14 Feb 2007
|
|
