Declared fields and methods:
group by access rights from public to private (alphabetical order
maybe for ease of finding them later).

In java you have to declare each method for any number and types of
params you may want to use, i.e.
myMethod(String param1, Object param2, int param3){
... common processing here ...
}
myMethod(String param1, Object param2){
myMethod(param1, param2, defaultValueForParam3)
}
myMethod(String param1){
myMethod(param1, defaultValueForParam2)
}

For parameters, I prefer to put the most optional ones at the end,
because I may want to do multiple constructors or methods, turning them
into optional parameters.

void doSomething(int param1, int param2, int param3, Object param4,
String param5){
...
}

void doSomething(int param1, int param2, int param3, Object param4){
  doSomething(param1, param2, param3, parm4, "black");
}
void doSomething(int param1, int param2, int param3){
  doSomething(param1, param2, param3, null);
}

Even if, initially, I'm only doing the first version, putting the
potentially optional parameters last leaves the door open to making them
optional later.

I tend to group data logically, because I use Eclipse a lot and its
package explorer lists alphabetically.

Patricia

I find that if I think I might want to re-order, add, or remove
parameters from a constructor or function that has a large number of
parameters already, I choose to use the Parameter Object, and have it
usually fulfill the Builder pattern as well.

class SomethingParams {
 private String param;
 private String blah;

 public SomethingParams setParam(String value) {
   param = value;
   return this;
 }

 public SomethingParams setBlah(String blah) {
   this.blah = blah;
   return this;
 }
}

doSomething(new SomethingParams().setBlah("My blah is better than your
blah").setParam(null));

You should also add a validation check (either as a method on
SomethingParams, or in doSomething) that throws an
IllegalArgumentException or some such, if the manditory arguments
aren't correctly set.

Also, at this point, you might consider whether or not doSomething
actually belongs in SomethingParams, and if SomethingParams can be
made to be more self contained.

Or, if you would pass this Param object into a constructor, use the
Factory pattern instead, and have a SomethingBuilder.newSomething(),
which calls the appropriate constructor for the client, based on the
other configuration they've done.

Eh. This is entirely stylistic, and up to each to determine.

Generally, I order the members of a class like this:

Constants (IE, static final fields)

Static variables (static, non-final fields)

Instance variables

Constructors (Generally fewer parameters to the complete list of parameters.
Generally, all constructors end up resolving to one in this class.)

Instance methods. (If I worry about order at all within this grouping, it
generally is by "topic." A grouping by topic tends to suggest an opportunity
for another class if you're into aggressive refactoring.)

Static methods, except "main."

Instance member classes

Static member classes

main method.

   As far as I know, there's no standard (defacto or otherwise) for the
order of class members. If your programming group has a specific standard,
follow that one. Otherwise, do whatever you want?

   Personally, I don't really care how my coworkers order the members,
because my IDE can present a sorted view of them without actually
manipulating them on the disk, so I see them in the order that I want to
see them.

   - Oliver