Bug 142899 - [sort members] More intelligent grouping when sorting members
Summary: [sort members] More intelligent grouping when sorting members
Status: ASSIGNED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: UI (show other bugs)
Version: 3.2   Edit
Hardware: All All
: P3 enhancement with 1 vote (vote)
Target Milestone: ---   Edit
Assignee: JDT-UI-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: helpwanted
: 257148 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-05-20 21:17 EDT by Missing name Mising name CLA
Modified: 2018-08-16 10:57 EDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Missing name Mising name CLA 2006-05-20 21:17:48 EDT
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()
Comment 1 Martin Aeschlimann CLA 2006-06-08 12:36:31 EDT
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.
Comment 2 Dani Megert CLA 2008-12-19 03:50:54 EST
*** Bug 257148 has been marked as a duplicate of this bug. ***
Comment 3 Denis Roy CLA 2009-08-30 02:20:18 EDT
As of now 'LATER' and 'REMIND' resolutions are no longer supported.
Please reopen this bug if it is still valid for you.
Comment 4 Ewa Sliwinska CLA 2018-08-14 13:10:32 EDT
How to reopen a bug?
Comment 5 Andrey Loskutov CLA 2018-08-14 13:20:37 EDT
Reopened as requested
Comment 6 Ewa Sliwinska CLA 2018-08-16 10:57:46 EDT
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.