# (Wie) sortiert ihr eure Felder, Methoden, etc?



## -frank (21. Aug 2007)

mich würde interessieren, ob ihr eure felder, methoden, kontruktoren, etc. speziell sortiert und wenn ja wie und warum. und wenn ihr fremden code anseht und ne methode sucht, benutzt ihr dann sowieso suchfunktionen (bzw. irgendwelche IDE views) oder geht ihr zb davon aus, dass methoden, die miteinander zu tun haben, untereinander stehen? order erwartet ihr ne alphabetische reihenfolge? wollt ihr, dass die static methoden/felder ganz oben/unten im file stehen? und wie siehts bei fields aus?

ich frage, weil ich gesehen habe, dass mir Eclipse anbietet den ganzen code zu sortieren und dabei sichtbarkeit, static/instance, alphabet, etc. berücksichtigt. ich hab mir den code bisher immer selbst sortiert. das führt nach meinem gefühl an manchen stellen zu nem guten ergebnis, an anderen, wos mir nicht wichtig schien, zu einem vollkommen unsortierten file...

was ist euch lieber? (sowohl beim eigenen code wie auch wenn ihr euch in fremden code einarbeiten müsst?)


----------



## Rock Lobster (21. Aug 2007)

Meine Member-Variablen sortiere ich nach Sinn und Zweck, allerdings nicht getrennt in private und public, da die meisten sowieso private sind und der Sinn für mich wichtiger ist.

Die Methoden sortiere ich ähnlich, passende setter und getter natürlich untereinander, Konstruktoren ganz oben, und dann nach Wichtigkeit. Methoden, die aus Interfaces geerbt sind, kommen bei mir meist nach unten (besonders wenn es Listener sind). Wenn zwei Methoden miteinander zu tun haben, z.B. weil eine die andere aufruft, dann stehen diese bei mir auch oft direkt untereinander.

Naja Ordnung halten ist immer so ein Ding, jeder hat so seine eigenen Vorstellungen, und es gibt viele Fälle, wo man eben Ausnahmen macht oder ein bestimmtes Schema halt nicht paßt, und dann wächst und wächst das... wenn's zu unübersichtlich wird, überlege ich allerdings, ob es sinnvoll wäre, die Klasse aufzuteilen oder sie mit einer anderen zu "verheiraten" (z.B. daß man zwischen zwei Klassen Abhängigkeiten findet, die man über Vererbung oder sowas klüger realisieren kann). Manchmal ist das eine sehr gute Lösung.


----------



## thomator (21. Aug 2007)

Also statics sind bei mir immer am Ende einer Klasse zu finden. Andere Variablen am Anfang. Sonst nix Besonderes, da ich eh mit Eclipse arbeite, wo man die Super-Buper Outline zur verfügung hat.
Is scho ein feines Arbeiten mit Eclipse... :wink:


----------



## FelixB (21. Aug 2007)

oben erstmal die Variablen, dann die Konstruktoren. Die Getter/Setter ganz nach unten, der Rest - meistens in der Reihenfolge, wie ich sie code 

zum Navigieren gibts dann in Eclipse ne schöne Outline-View bzw. andere nette Sachen (Call-Hierarchie etc...)


----------



## -frank (21. Aug 2007)

okay, bei mir ist das recht ähnlich. ich habe meine variablen eigentlich fast immer ganz oben, nicht nur die static. und static methoden kommen meisten ganz nach unten. innere klassen entweder ganz unten oder wenn sie ganz kurz sind eben zu den 2-3 methoden, die sie brauchen. kontruktoren immer ganz oben. also eh ähnlichkeiten mit euch.
das widerspricht aber recht stark den conventions von sun http://java.sun.com/docs/codeconv/html/CodeConventions.doc2.html#1852

frag mich halt jetzt, ob ich mich an die halten soll oder nicht...


----------



## bygones (21. Aug 2007)

variablen oben, static, finals und instanzvar. getrennt, dann konstruktor, dann irgendwelche methoden..

dank den IDEs achte ich nicht so darauf wann wo welche methode steht... die Trennung von Methoden und Variablen sind mir schon wichtig (zuerst variablen, dann methoden)


----------



## Evil-Devil (21. Aug 2007)

ERstmal Header Comment, Packages, Class Deklaration

Dann Klassenvariablen und Konstruktor. Von da an geht es meist querbeet auch wenn ich nach möglichkeit setter und getter direkt nach dem konstruktor kommen zu lasse sofern es die gibt.

Ich nutzt die Outline der IDE sehr viel, von daher mach ich mir recht wenig Gedanken um ein spezielles Code Bild. lokale Variablen werden da deklariert wo sie gerade benötigt werden.


----------



## Rock Lobster (21. Aug 2007)

Ich hab die Outline zwar offen, aber benutz sie doch eher selten, weil meist weiß ich irgendwie, wo meine Methoden sind. Nur wenn ich wirklich zu faul zum Scrollen bin oder ich sie nicht sofort finde, schau ich in der Outline nach. Eigentlich blöd, weil man in der Outline viel schneller fündig wird. Aber irgendwie hab ich mich nie so recht daran gewöhnt


----------



## thomator (21. Aug 2007)

Ich hab die Outline nicht offen, wenn ich was suche STRG+F3, dann kann ich via Eingabe von Anfangsbuchstaben sogar die Auswahl einschränken...


----------



## Tobias (21. Aug 2007)

static final Konstanten

public static Variablen
private static Variablen

static Methoden

public Variablen (gibt es fast nie)
private Variablen

Konstruktoren

setter/getter

API-Methoden (hier stehn auch protected Methoden, weil die quasi API für Subklassen sind)

private Methoden

mpG
Tobias


----------



## Wodan (22. Aug 2007)

> Reihenfolge der Eigenschaften in Klassen
> 
> Verschiedene Elemente einer Klasse müssen in einer Klasse untergebracht werden. Eine verbreitete Reihenfolge ist die Aufteilung in Sektionen:
> 
> ...



^^hab ich eben in der Java ist auch eine Insel gelesen:Kapitel 6.7.17


----------



## Jango (22. Aug 2007)

Wodan hat gesagt.:
			
		

> ^^hab ich eben in der Java ist auch eine Insel gelesen:Kapitel 6.7.17


Dann würde ich das mal schnellstens in ein Zitat umändern. Du kannst nicht wahllos alles kopieren und einfügen, wie du es willst. Schonmal das Wort "*Kopier*"-Recht gehört?  :wink:
Andernfalls wird es ein Moderator löschen (müssen).


----------



## AlArenal (22. Aug 2007)

Interessant, dass hier bisher niemand gepostet hat, der den Stil praktiziert Variablen ans Ende der Klasse zu setzen. Der Stil begegnet mir in vielerlei kommerziellen und freien Projekten.


----------



## Evil-Devil (22. Aug 2007)

Doch, Frank hat das in seinem Beitrag geschrieben das er das macht


----------



## AlArenal (22. Aug 2007)

Evil-Devil hat gesagt.:
			
		

> Doch, Frank hat das in seinem Beitrag geschrieben das er das macht



Ja, wo denn?



			
				-frank hat gesagt.:
			
		

> okay, bei mir ist das recht ähnlich. *ich habe meine variablen eigentlich fast immer ganz oben, nicht nur die static.* und static methoden kommen meisten ganz nach unten. innere klassen entweder ganz unten oder wenn sie ganz kurz sind eben zu den 2-3 methoden, die sie brauchen. kontruktoren immer ganz oben. also eh ähnlichkeiten mit euch.
> das widerspricht aber recht stark den conventions von sun http://java.sun.com/docs/codeconv/html/CodeConventions.doc2.html#1852
> 
> frag mich halt jetzt, ob ich mich an die halten soll oder nicht...


----------



## byte (22. Aug 2007)

Wenn ich neue Klassen erstelle, lasse ich sie vor dem Commit von Eclipse sortieren nach den Standardvorgaben. Danach sortiere ich nichts mehr um, weil das im Zweifel nur zu Team-Conflicts führt und man nervig mergen muss. Ich navigiere eh nur über den Outliner und den kann man ja eh bei Bedarf sortieren/ filtern, ohne dass die Sourcen verändert werden.


----------



## AlArenal (22. Aug 2007)

Ich glaub die wenigsten hier nutzen ein RCS


----------



## Saxony (22. Aug 2007)

Wodan hat gesagt.:
			
		

> [...]
> 
> * Klassenvariablen
> 
> ...



Hmm, da steckt aber mal wieder der Teufel im Detail.

Für mich sind Klasssenmethoden schon statische Methoden. 

Bei diesen Namenskonventionen (Klassen- / Objektvariablen) müsste man dann konsequenterweise auch von Klassen- /Objektmethoden sprechen.

bye Saxony


----------



## Evil-Devil (22. Aug 2007)

AlArenal hat gesagt.:
			
		

> Evil-Devil hat gesagt.:
> 
> 
> 
> ...


Bring mir mehr Kaffee!


----------



## Saxony (23. Aug 2007)

Hiho,

zusammenfassend kann man ja sagen, dass es besser ist nicht alles auf eine Zeile zu schreiben.

Ich hoffe aber das wenigstens die Tabs ordentlich gesetzt werden - in Eclipse bitte Ctrl+Shift+F verwenden. 

bye Saxony


----------

