Members sort order

codeconvention
reihenfolge

#1

Hallo zusammen,

bei uns im Projekt gab es letztens eine Diskussion zu unseren Code-Richtlinien. Hauptthema war dabei die Reihenfolge der Klasseninhalte, also statische/nicht statische Felder und Methoden usw.

Ich persönlich bevorzuge: alle Felder zu Beginn der Klasse, dann Konstruktoren und dann Methoden. Ob statisch oder nicht ist mir dabei egal. Felder bzw- Methoden “thematisch” gruppiert

Meinung vom Kollegen: erst alles statische und dann der Rest und diese zwei “Kategorien” sortiert nach Feldern und Methoden.

Oracle selber hat dazu auch keine Aussage gemacht http://www.oracle.com/technetwork/java/codeconventions-141855.html und selbst bei Google scheint man die Reihenfolge nicht vorschreiben zu wollen https://google.github.io/styleguide/javaguide.html#s3-source-file-structure

Wenn ich bei Eclipse und NetBeans rein schaue, haben die eine Reihenfolge die stark in die Richtung meines Kollegen geht. Leider hab ich bisher nicht heraus gefunden, worauf diese Standard-Einstellungen beruhen.

Eclipse:

Netbeans:

Jetzt zur eigentlichen Frage: Wie macht ihr das privat oder bei euch in der Firma/Projekt?

Wir sind uns noch nicht einig, ob man das überhaupt definieren muss oder ob das dann eben persönliche Vorliebe ist.


#2

Also ich mach das so:

  1. static variables
  2. member variables
  3. static methods
  4. constructors
  5. public methods
  6. protected method
  7. private methods

Prinzipiell gilt aber: Kompromiss im Team vereinbaren und dann mittels Autoformatter durchsetzten.

bye
TT


#3

Darum gehts ja im Grunde. Mir war es bei unserem letzen Code-Review aufgefallen, dass der Kollege seinen Code so sortiert hat und für mich sah es komisch aus. Ich habe mir bisher aber auch keine Gedanken darum gemacht.


#4

Obwohl ich sonst in bezug auf viele Codestil-Sachen ziemlich nazihaft sein kann, ist das eine Ausnahme: Mal so, mal so, wie es gerade passt.

Ich würde, ganz subjektiv, die Methoden nicht nach Sichtbarkeit ordnen, sondern eher subjektiv gruppieren:

public void computeFoo() {
    computeFooHelperInternalA();
    computeFooHelperInternalB();
}
private computeFooHelperInternalA() { ... }
private computeFooHelperInternalB() { ... }

public void computeBar() {
    computeBarPartA();
    computeBarPartB();
}
private computeBarPartA() { ... }
private computeBarPartB() { ... }

Aber zugegeben: Da mit mit STRG+Klick sowieso zu den Helpern hüpfen kann, gibt es dafür kein starkes Argument…

@Timothy_Truckle :

  1. static variables
  2. member variables
  3. static methods
  4. constructors

D.h. da steht static und nicht-static gemischt? Ich würde ja

// static variables
// static methods
// member fields
// constructors
// member methods

verstehen, aber die fields zwischen den static fields und static methods zu haben (wo sie ja nun wirklich nicht “reinpassen”) finde ich seltsam.

Ich schreibe static Methods oft ganz nach unten, vor allem, wenn es irgendwelche “unwichtigen” kleinen, internen Helper sind. (Wenn sie nicht unwichtig sind, landen sie meistens sowieso in einer eigenen Klasse, wo sie dann package-visible sind)


#5

Ja.

Da ich aber (außer Konstanten) im Regelfall keine static Variablen habe ist das zu verschmerzen…

bye
TT


#6

Dann eben der inverse Fall: Was haben static methods zwischen Membervariablen und Konstruktoren verloren? (Gerade, die Initialisierung der Variablen (in den Konstruktoren) auf einen Blick zu haben, finde ich wichtig…).

(Das kommt davon, wenn es für irgendwas keine offiziellen Regeln von Sun/Oracle gibt :unamused: )


#7

Ich wäre da ganz auf Marcos Seite. Die Member-Methoden nach public, protected und private zu sortieren, halte ich für überflüssig, dann lieber thematisiert.

Allerdings habe ich auch etwas, was gar nicht geht… Statisch und Instanz beliebig gemischt und obendrein Variablen immer genau dort definiert, wo sie zum ersten mal verwendet werden. Was? Das geht doch? Stimmt schon, aber es sollte verboten werden.


#8

Sofern sich das nicht auf Member-Variablen (fields) bezieht, würde ich sagen: Doch, wo denn sonst?

Aber ich gehe davon aus, dass du NICHT sowas meinst wie

private int usedInFoo;
public void foo() { ... }

private int usedInBar;
public void bar() { ... }

… das wäre einfach ZU schräg :confused:


#9

Äh doch… genau das meinte ich. Vllt. hätte ich Membervariablen dazu schreiben sollen, aber ich nahm an, dass man das erkennt, wo doch zuvor genau von solchen auch die Rede war.


#10

OK, konnte mir nur nicht vorstellen, dass jemand das wirklich macht. Ich meine, … das ist keine “Timeline”. Die Member-Fields bilden den Zustandsraum eines Objektes, und der sollte so klein und klar (und dokumentiert) und übersichtlich sein wie möglich …


#11

Hab mal nachgeschaut:

Members Sort Order:

  • Static Fields
  • Static Initializers
  • Static Methods
  • Fields
  • Instance Initializers
  • Constructors
  • Methods
  • Static Classes
  • Classes
  • (Main…)

Sort Members By Visibility:

  • Public
  • Private
  • Protected
  • Default

Keep Getters And Setters Together

Sort Members in Groups Alphabetically (*)

Sort uses dependencies

Use Package Imports, NOT Single Class Imports (!)

NOT Prefer Static Imports


(*) : Zugegeben, die alphabetische Sortierung von Members Gruppen kann extrem nervig sein, meist ist diese Option nicht aktiviert.

(**) : Manchmal(!), aber sehr selten, schreibe ich die Felder auch zu den Methoden - das ist aber immer ein deutlicher Hinweis darauf, dass eine Klasse vertikal zu lang ist!

Außerdem könnte so schnell fälschlicherweise angenommen werden, Fields (/Methods) besitzen denselben inner scope wie Local Variables.

hth :slight_smile:


#12

Aber woher dieser verbreitete Konsens der Reihenfolge kommt, wie in Eclipse und NetBeans, weiß von euch auch keiner so genau?


Wir werden uns vermutlich an den Vorschlägen der IDE orientieren. Das macht es für uns erstmal einfacher.


#13

Ich meine das war mal im Java Styleguide von Sun so vorgeschlagen, aus dem link (http://www.oracle.com/technetwork/java/codeconventions-141855.html)

D.h. man hat es einfach so mal festgelegt :wink: