Java has a Sort Members operation, which allows you to sort the order of the fields, methods and constructors inside the source file. It seems to be under used by Eclipse developers; either because they don't know it's there, or because it's not easy to get at. It's got some usability issues -- it only works on a file-by-file basis, not a project/package, and it doesn't have a keystroke -- which makes it a little bit more difficult to use but not impossible.

(I'm working on adding the Sort Members functionality to the Clean Up page, which will make it easier both to apply and also to apply to project-wide contents, or even with the Clean Up on save option.)

So, what does the sort members do? Well, you can chose whether you want to have methods or methods+fields sorted, so that:

public class ToSort {
  int b;
  int a;
  void d() {}
  void c() {}
}

will become either

public class ToSort {
  int b;
  int a;
  void c() {}
  void d() {}
}

or

public class ToSort {
  int a;
  int b;
  void c() {}
  void d() {}
}

Why not sort fields? Well, there's cases where re-ordering the fields *may* cause initialisation problems. For example, if we had:

int b = 3;
int a = 2*b;
[code]
 
then the code would compile; but if it were sorted:
 
[code]
int a = 2*b;  // b is not defined at this point
int b = 3;

this would be a compile-time error. Fortunately, such cases are rare in Java (though not impossible) so whilst it's not guaranteed 100% safe, it's actually sufficiently rare that it makes sense to do this.

(NB it also sorts Enums as well, which if you're wanting to use the auto-numbering can be an issue.)

So, what benefit is there for sorting members? Well, like a good coding convention, if everyone follows it it makes it a lot easier to find what's going on. In addition (also like coding conventions) if you always sort members then it makes diffs with a remote server much easier to understand.

A sorted member has exactly one place where it should be inserted, and anyone who adds members and sorts will see the same behaviour. On the other hand, a large number of Java files just have methods tacked onto the end, which results in a more haphazard file. (See the contents of the average Java class library's .class files, in which the order of methods corresponds to the order in the source. They're all over the place.)

The other thing about sorting members is that it's unambiguous. None of the special cases (e.g. 'except when it's a getter/setter' or 'if they are in the same interface' or 'which delegate to another object') -- which may well overlap (e.g. what rule do you follow with methods 'a','b','c','d' when 'a' and 'c' are in one interface, 'b' and 'd' are in another interface, and 'a' and 'd' are in a third interface? And what about the ineffable equals/hashcode?

Sorting is really the only pragmatic way of ordering the methods that's clear, unambiguous, and will help with any diffs. The only real wonder is why people don't use it more; but like I hinted at the start, it's probably because it's not easy to sort members; with any luck, that will be easier soon. Fortunately, if you have to work with an unsorted file, you can select 'A-Z' on the Members toolbar to see an alphabetical list of the members.

One of the things that Mylar will help with everyone is that a Java source file isn't just a source file; it's a class definition, that contains members. If you've come from a Visual Age for Java background with its object-oriented rather than file-oriented view (and yes, obligatory Smalltalk comment where applicable), then you'll be used to thinking of a program in terms of objects and methods, not in terms of chars and files. Unfortuantely, many Java developers still think of a .java file as text instead of as a representation of an object. Mylar will force people to reconsider by having automatic hiding of irrelevant methods/fields, and hopefully encourage people to start thinking of .java files as class definitions instead of text files.

Alex.