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.
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.
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.
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)
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 )
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.
Ä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.
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 …
(*) : 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.