Community
Participate
Working Groups
Currently the member sorter orders first by type, optionally by visibility and then by name. This neglects the meaning of the members, which can sometimes be reasonably deduced. There should be customisable grouping options such as grouping accessors/mutators and collecting methods together that are declared in the same interface. For instance, consider the following code: interface ITwoWays { public void accept(); public void reject(); } public class FruitAudit implements ITwoWays { public int getApples() {return 1;} public void setCherries(boolean b) {} public boolean isBananas() {return false;} public void accept() {} public void setApples(int n) {} public void finalize() {} public boolean hasCherries() {return true;} public void reject() {} public void init() {} public void setBananas(boolean b) {} } The methods in the FruitAudit class are sorted as follows using the current algorithm: accept() finalize() getApples() hasCherries() init() isBananas() reject() setApples() setBananas() setCherries() It would be clearer to group accessors, mutators and other special methods, and have setup/teardown methods near the top, such as in: // Setup/teardown, sorted by execution order init() finalize() // Accessors, sorted by variable getApples() isBananas() hasCherries() // Mutators, sorted by variable setApples() setBananas() setCherries() // Remaining methods, sorted alphabetically accept() reject() or having accessor/mutator pairs, sorted by variable: // Setup/teardown init() finalize() // Apples getApples() setApples() // Bananas isBananas() setBananas() // Cherries hasCherries() setCherries() // Remaining methods accept() reject() Even with the existing sorting it would be helpful to collect methods by the (alphabetically first) interface in which they are declared when the class directly implements one or more interfaces. For example: // Original and overiding methods finalize() getApples() hasCherries() init() isBananas() setApples() setBananas() setCherries() // Implementation of methods declared in ITwoWays accept() reject()
Agreed, there are better sorting orders than alphabetical. However, we don't want to evolve the sort member feature any further because of time constraints. Contributions are highly welcome.
*** Bug 257148 has been marked as a duplicate of this bug. ***
As of now 'LATER' and 'REMIND' resolutions are no longer supported. Please reopen this bug if it is still valid for you.
How to reopen a bug?
Reopened as requested
Thanks. I would to like to have auto-sorting with ability to set it up the way Checkstyle requires it in http://checkstyle.sourceforge.net/config_coding.html#DeclarationOrder.