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

[-frank]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Reihenfolge der Eigenschaften in Klassen

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

* Klassenvariablen

* Objektvariablen

* Konstruktoren

* Methoden (erst Klassenmethoden, dann statische Methoden)

Innerhalb eines Blocks werden die Informationen oft auch bezüglich ihrer Zugriffsrechte sortiert. Am Anfang stehen sichtbare Eigenschaften und tiefer private. Der öffentliche Teil befindet sich deswegen am Anfang, da wir uns so schnell einen Überblick verschaffen können. Der zweite Teil ist dann nur noch für die erbenden Klassen interessant, und der letzte Teil beschreibt allein geschützte Informationen für die Entwickler. Die Reihenfolge kann aber problemlos gebrochen werden, indem private Methoden hinter öffentlichen stehen, um zusammenhängende Teile auch zusammenzuhalten.

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

 

[Jango]

^^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]

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]

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

 

[AlArenal]

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

Ja, wo denn?

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]

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]

Ich glaub die wenigsten hier nutzen ein RCS

 

[Saxony]

[...]

* Klassenvariablen

* Objektvariablen

* Konstruktoren

* Methoden (erst Klassenmethoden, dann statische Methoden)

[...]

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

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]

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

Ja, wo denn?

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...

Bring mir mehr Kaffee!

 

[Saxony]

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