Bug 413009 - feature request for better member sorting (used in formatter) with Java classes
Summary: feature request for better member sorting (used in formatter) with Java classes
Status: NEW
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 4.4   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: JDT-Core-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-07-15 16:55 EDT by Tony Herstell CLA
Modified: 2013-07-18 04:11 EDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Dani Megert CLA 2013-07-16 09:15:02 EDT
(In reply to comment #0)
> http://www.eclipse.org/forums/index.php?t=rview&goto=1069336#msg_1069336

Please put your original request into this bug report, so that it is self-contained.
Comment 2 Tony Herstell CLA 2013-07-16 16:23:55 EDT
Hi Guys, 

From my old Ada days we always force the code through the formatter before checking it in. 

I still enforce this "good habit" myself... well the formatter needs a fixup... for Java anyhow. 

If you use it you will see what I mean!!!! 


This is what I suggest it does to REALLY rock: 

All below in alphabetic order unless specified 

AND... if possible... all below in folding areas unless specified 

Static logging stuff at the top. e.g. 

Code: [Select all] [Show/ hide]
private final Logger logger = Logger.getLogger(GroupingManagementActionController.class.getName()); 

Scan for the word log? 

Next "contextual" stuff like: 
Code: [Select all] [Show/ hide]
@Inject 
private Conversation conversation; 

Code: [Select all] [Show/ hide]
@PersistenceContext(type = PersistenceContextType.EXTENDED) 
private EntityManager em; 


Next "contextual" Event stuff like: 

Code: [Select all] [Show/ hide]
// Events 
@Inject 
@GroupingCreateEvent 
private Event<Grouping> createEvent; 


The other @injects... 

Code: [Select all] [Show/ hide]
@Inject 
GroupingManagementActionController groupingManagementActionController; 


Next "leading" (Cruffy) stuff like ID and Version for Entities 

Code: [Select all] [Show/ hide]
@XmlAttribute 
@XmlID 
@XmlJavaTypeAdapter(IdAdapter.class) 
@Id 
@GeneratedValue 
private Long id; 

@NotNull 
@Version 
@Column(name = "version4OptLock") 
private long optlock; 


Next the "simple" private members 

Code: [Select all] [Show/ hide]
@XmlElement(name = "nots") 
@Column(name = "notes", length = 1000) 
@Length(max = 1000) 
private String notes; 

Next the Lists/Sets ... 


1..* 

Code: [Select all] [Show/ hide]
@XmlElement(name = "tasks") 
@OneToMany(fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }, mappedBy = "grouping") 
private Set<GroupingTask> tasks; 


*..* 

Code: [Select all] [Show/ hide]
@NotNull 
@ManyToMany(fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }) 
private Set<OrganisationRole> organisationRoles; 


*..1 (generally backlinks) 

Code: [Select all] [Show/ hide]
@XmlElement(name = "parent_organisation") 
@XmlIDREF 
@NotNull 
@ManyToOne(fetch = FetchType.EAGER) 
// -> DO NOT ADD IN AS BREAKS CREATE!// , cascade = { CascadeType.MERGE, CascadeType.PERSIST, CascadeType.REFRESH } 
private Organisation parentOrganisation; 


Next Constructors 

Next @Overridden methods from parent classes 

Next methods with names like init, create etc. (that logically would come first) 

Next the putters/getters that match the members by public/private 

Next other putters/getter for non members by public/private 

Next the public methods (followed by any truly private methods they (or their neighbours) completely "own") 

Next the private methods (followed by any truly other private methods they (or their neighbours) completely "own") 

Finally methods life @Destroy, cancel, done or similar. 

I am sure you can think of more! 

Cheers.
Comment 3 Stephan Herrmann CLA 2013-07-17 15:55:43 EDT
Do I understand correctly, that you want to super-impose a master order of
groups of members, to have alphabetical ordering only *within* these groups?

From a quick lock I feel that you are implying a lot of semantics in specific
annotations, I don't even know where all these are specified. 
With this in mind your RFE might be better addressed by a plugin that supports the
particular technology that introduces the annotations, not by a general Java IDE?

Given the length of the proposed list of groups and the fact that this still is
incomplete I doubt that there's an easy way to realize this in a fashion that
meets the tastes of many users. How could this be made sufficiently flexible without
overwhelming users with too many new configuration options?
Comment 4 Tony Herstell CLA 2013-07-18 04:11:20 EDT
>> With this in mind your RFE might be better addressed by a plugin that supports the particular technology that introduces the annotations, not by a general Java IDE?

I believe eclispe is a Java IDE.
And since JEE 7 is pretty "standard" I am struggling to see your logic.
Most of the annotations I supplied were stright out of JEE 7 ... in fact JPA, CDI  etc.

>> Given the length of the proposed list of groups and the fact that this still is
incomplete I doubt that there's an easy way to realize this in a fashion that
meets the tastes of many users. How could this be made sufficiently flexible without overwhelming users with too many new configuration options?

I know from experience that people don't even try to use the Eclipse formatter any more as it's just so bad; so any improvement on that would be a benefit.


I will ave a word with the MyEclipse guys as they have added significant improvements over basic eclipse and this simple enhancement may help their cause.

Thx anyhow.

Feel free to close this.