Programmierstil

Hallo,

ich weiss, über Programmierstile lässt sich streiten.
Aber dennoch:

Die SUN Coding Conventions sehen vor, dass die Variablen immer zu
Beginn in der Klasse stehen sollen.

Wenn ich jedoch eine Klasse im Quelltext vor mir habe, interessiere ich mich aber primär dafür, wie ich diese Klasse benutzen kann und muss dann immer erst nach unten scrollen.

Ich würde deswegen eher vorziehen, die Attribute ans Ende der Klasse zu stellen. Jede IDE die ich kenne, sortiert im Class-Browser die Sache ebenso.

Was spricht dafür und was dagegen, die Attribute ans Ende der Klasse zu stellen?

Dirk

Was spricht dafür und was dagegen, die Attribute ans Ende der
Klasse zu stellen?

Vermutlich nichts dafür und dagegen, mich aber stört es wenn die Variablen am Ende stehen (wenn ich z.b. mit jad eine .class decompile)

Ich suche die Variablen nämlich immer oben und blicke dann gar nicht mehr durch…

Hi.
Wenn du wissen willst, wie du eine Klasse verwenden kannst, sollte normalerweise der Blick in die Doku der Klasse gehen (wenn sie denn da ist). Den Quellcode schaut man sich ja eigentlich an, weil man ihn z.B. erweitern will oder verstehen möchte, wie etwas implementiert wurde. Dazu ist es aber gut, die Variablen zu kennen, die verwendet werden, weshalb diese am Anfang aufgeführt werden.
Natürlich gibt es auch Gründe, es anders zu machen, deshalb gibt es ja auch andere Konventionen. Die Konvention von SUN sieht es halt so, dass die Vars vorne stehen.
CU,
Sebastian.

Hi.
Wenn du wissen willst, wie du eine Klasse verwenden kannst,
sollte normalerweise der Blick in die Doku der Klasse gehen
(wenn sie denn da ist). Den Quellcode schaut man sich ja
eigentlich an, weil man ihn z.B. erweitern will oder verstehen
möchte, wie etwas implementiert wurde. Dazu ist es aber gut,
die Variablen zu kennen, die verwendet werden, weshalb diese
am Anfang aufgeführt werden.

Verstehe ich nicht. Wieso muss ich die Variablen einer Klasse kennen. Als Anwender einer Klasse sollte es mir doch eigentlich wurscht sein, welche Variable das Ding verwendet. Ausnahme mögen da Attribute nach dem Bean-Pattern sein, da ich dann immer 2 Methoden im Auge haben muss. Aber was interssiert mich eine lokale Variable der Klasse, die ich nach aussen hin nieh verwenden kann, weil ich keinen Zugrif darauf habe?

Dirk

Hi.
Als Anwender musst du die auch nicht kennen. Aber als Anwender einer Klasse solltest du eigentlich nicht den Quellcode sondern die Dokumentation ansehen um zu sehen, was die Klasse macht und wie du sie benutzen kannst. Den Quellcode schaust du dir ja eigentlich an, wenn du die Klasse veraendern musst, weil z.B. ein Fehler vorliegt oder so. Dazu musst du aber genau wissen, wie die Klasse irgendetwas macht. Und da sie dazu die Variablen verwendet, ist es eigentlich ganz gut zu wissen, welche es gibt. Natuerlich ist das Geschmackssache und einige moegen das vielleicht lieber anders, aber deshalb gibt es ja auch andere Konventionen.
CU,
Sebastian.

Hallo Dirk!

Fangen wir mal ganz vorne an: Eine Klasse hat Attribute und Methoden. Dabei kann eine Methode natürlich auch wieder Variablen haben - das sind dann meist die Variablen, die Du nie zu Gesicht bekommst, weil sie nur in dieser Methode vorkommen und nicht als Attribut gelten (das Wort Attribut wurde nicht umsonst gewählt). Dagegen sind Klassen-Attribute meist schon sehr viel wichtiger. Ein Beispiel:
Es gibt die Klasse Auge die ein Attribut „farbe“ hat und ein final static Attribut int für den Druck im Auge hat (angenommen 1 für normal) und einen, für den gerade aktuellen Druck im Auge. (Über die Sinnhaftigkeit einer solchen Implementation lässt sich natürlich streiten - aber darum geht es hier ja nicht).
Diese würde dann z.B. so aussehen:

public class Auge
{
 private String farbe;
 final static float solldruck = "1";
 private float aktuellerdruck;
}

Jetzt willst Du entsprechende Methoden definieren:
getAugenfarbe() um die Augenfarbe zu erhalten und natürlich auch
getDruck() um den Druck zu erhalten, der beim Auge normalerweise da ist und natürlich auch getAktuellerDruck() um zu erfahren, wie der gerade aktuelle Druck im Auge ist.

Also sieht das ganze jetzt so aus:

public class Auge
{
 private String farbe;
 final static float solldruck = "1";
 private float aktuellerdruck;

 public String getFarbe()
 {
 return farbe;
 }

 public int getDruck()
 {
 return solldruck;
 }

 public float aktuellerDruck()
 {
 retun aktuellerdruck;
 }
}

Jetzt noch kurz entsrechende Konstruktoren eingebaut…

public class Auge
{
 private String farbe;
 final static float solldruck = "1";
 private float aktuellerdruck;

 public Auge()
 {
 this.farbe = "keine"; //wie gesagt: Über Sinn und Unsinn lässt sich streiten
 this.aktuellerdruck = "0";
 }

 public Auge(String farbe, float aktuellerDruck)
 {
 this.farbe = farbe;
 this.aktuellerdruck = druck;
 }

 public String getFarbe()
 {
 return farbe;
 }

 public int getDruck()
 {
 return solldruck;
 }

 public float aktuellerDruck()
 {
 retun aktuellerdruck;
 }
}

Ich denke mal, dass jetzt relativ schnell klar wird, dass wenn Du Dir nicht die ganzen Attribute anschaust Du sonst keine Ahnung hast, wann z.B. farbe gesetzt wurde und was da genau zurückgeliefert wird. Schlimmer ist der Sachverhalt natürlich in etwas komplexeren Umgebungen wo dann z.B. auch noch etwas mit oder an den Attribute geändert wird um es Dir dann zu liefern. Da hast Du dann spätestens keine Ahnung mehr, wie Du es zu benutzen hast, wenn Du nicht zuerst einen Blick auf die entsprechenden Attribute geworfen hast.

Natürlich brauchst Du das nicht, wenn der Code entsprechend gut dokumentiert wurde (JavaDoc sei Dank!). Aber wenn Du mit mehreren Leuten an ein und dem selben Projekt sitzt wird so etwas ganz schnell unverständlich - und das kostet Zeit und Nerven. Beides sind Faktoren von denen meist nicht unendlich viel vorhanden sind. Also wenn Du es schon nicht aus Eigeninteresse so tun willst, dann richte Dich doch zumindest aus sozialen Gründen danach - später wirst Du vielleicht doch einmal genau das gleiche Problem haben und dann wärst Du froh wenn derjenige die Dokumentation entsprechend gelesen hätte um diese Coding Conventions einzuhalten.

Gruss

Hannes

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]