Was ist ein ... aehh ... Styleguide?

CengizS

Hallo zusammen,

ich würde gerne einmal von Euch wissen wie ihr es bzgl. Styleguide etc. habt. Wird in euerer Firma oder auch privat ein Programmierstyleguide vorgelegt und wie sieht dieser konkret aus? Welche Bereiche umfasst er bzw. was sollte er alles beinhalten? Welche Themen würdet ihr ändern und warum? Schreibt doch einfach mal auf, was Eurer Meinung nach in einen Styleguide stehen sollte mit Beispielen etc.

Gregor

Du meinst mit Styleguide sowas, wie die Coding Conventions von Sun, oder?

Wenn ja : Ich habe natürlich garkeine, da ich meistens nicht im Team programmiere und meistens nur privat.

...das hat allerdings zur Folge, dass einige Konstrukte, die ich selten verwende, oft sehr unterschiedlich aussehen. Das ist z.B. bei anonymen inneren Klassen so.

gomberl

also wir in unserer firma haben recht freizuegige konventionen
wir nutzen sprechende namen und versuchen moeglichst gemeinsam eine guenstige oo kapselung unserer daten zu finden

zum thema programmieren an sich

die ueblichen konventionen
mit pre und postfixe erweiterungen

dokumentationsrichtlinien
erweiterungsrichtlinien

usw usf

allerdings das thema kommentieren muss ich bald mal wieder anschneiden
hab an meinem jetzigen projekt 2 wochen nicht kommentiert

da kann ich jetzt wieder stunden sitzen und kommentieren

regards

PS: irgendwelche spezifischen fragen?

Ste.fun

Hi Cengiz!

Guck mal hier: http://www.galileocomputing.de/openbook/javainsel/java-27.htm

viele Grüße
Stefan

Gregor

Original erstellt von CengizS:
Schreibt doch einfach mal auf, was Eurer Meinung nach in einen Styleguide stehen sollte mit Beispielen etc.

OK! Ich fange einfach mal an :

1. Einrückung :

Sollte man
[java]
methode ()
{
}[/code]
oder
[java]
methode (){
}[/code]
verwenden? Sollte man mit Leerzeichen, oder mit Tabs einrücken? Wieviele Leerzeichen sollte man verwenden, wenn man mit Leerzeichen einrückt.
...auch bei Dingen, wie "case" sollte die Einrückung geklärt werden.

2. Namenskonventionen :

Wie sollten Methodennamen, Variablennamen, Klassennamen und Konstantennamen aussehen? Was soll groß geschrieben werden und was soll klein geschrieben werden. Was für Wörter sind wofür erlaubt? Müssen Methodennamen z.B. Verben enthalten?

3. Leerzeichen :

Wann sollten Leerzeichen benutzt werden? Sollte man "i<j" oder "i < j" schreiben,...?

4. Kommentare :

Was sollte alles kommentiert werden, wie detailiert sollte kommentiert werden und wie sollen Kommentare überhaupt aussehen? Wo sollen Kommentare stehen? (Ich finde Kommentare hinter Codezeilen z.B. sehr hässlich)

... (Jetzt kann wer anderes weitermachen)

Ste.fun

Hallo!

Also in letzter zeit beschäftige ich mich nur noch mit GUI-Programmierung. Nun, was für Namen benutzt ihr für eure GUI-Komponenten? In den Codeing Standards der Firma in der ich zuletzt arbeitete, stand nur drin, dass die namen verständlich sein sollten, z.B. "okButton". Ich bevorzuge es allerdings zu schreiben: "button_ok". Folgen dann noch Buttons wie "button_chancel" und "button_apply" werden die im Baum der benutzten Entwicklungsumgebung alphabetisch angezeigt, was zu Folge hat, dass ich meine Komponeten/Methoden schnell finde. Selbes Spielchen treibe ich auch mit den ActionPerformedmethoden (actionPerformed_Methode[1..N]()).

Viele Grüße
Stefan

Mehr Diskussion bitte!

Gregor

Original erstellt von Ste.fun:
Ich bevorzuge es allerdings zu schreiben: "button_ok".

Ich bin ein "okButton"-Typ! Bei GUI-Komponenten schreibe ich die Art der Komponente immer hinten an den Variablennamen dran. ...und ich mag "_" in Variablennamen (und auch in anderen Namen) nicht! Ausnahme : Konstanten.

Ich bin für buttonOk da man dann sofort den Typ erkennt.

CengizS

Ich für meinen Teil versehe den Namen für grafische Komponenten stets mit einem Präfix wie btn für Button oder lbl für Labels. Der Rest des Namens dann wie in SUNs Vorschlägen. Ansonsten wie folgt

[java]while (...) {
...
}

public class XYZ
{
}

if (...) {
}

try {
...
} catch (...) {
}

public void function(parameter) {
...
}[/code]

Ste.fun

Original erstellt von Gregor:
und ich mag "_" in Variablennamen (und auch in anderen Namen) nicht! Ausnahme : Konstanten.

Jep! Geht mir da genauso. In der Regel lasse ich den Unterstrich auch weg, aber manchmal finde ich, dass er zu Lesbarkeit enorm beitragen kann (besonders natürlich bei konstanten, wie du schon sagtest, oder bei etwas sehr langen Methodennamen).

Apropos Methodennamen, wie lang sollten diese eurer Meinung nach sein? Ich neige dazu Methoden extrem zu verschachteln, da sind lange Methodennamen sehr hinderlich, wenn man eine Zeilenbeschränkung von max. 80 Zeichen einhalten möchte...

Gregor

Original erstellt von Ste.fun:
**
Apropos Methodennamen, wie lang sollten diese eurer Meinung nach sein? Ich neige dazu Methoden extrem zu verschachteln, da sind lange Methodennamen sehr hinderlich, wenn man eine Zeilenbeschränkung von max. 80 Zeichen einhalten möchte...**

Jo! Die sind schon hinderlich, trotzdem bevorzuge ich lange Methodennamen vor kurzen, nichtssagenden Methodennamen oder Methodennamen, die aus Abkürzungen bestehen, die man nach 2 Wochen vergessen hat! (meistens)

Mein Lieblingsbeispiel, für etwas, was bei mir viel zu lang geworden ist, ist:

HistogramEqualizerController.ADAPTIVE_NEIGHBORHOOD

@ CengizS : Warum machst du die Einrückung bei Klassen anders, als beim Rest?

Gregor

Original erstellt von Ste.fun:
Ich neige dazu Methoden extrem zu verschachteln

Ich versuche inzwischen, starke Verschachtelungen zu beseitigen bzw. zu umgehen. Verschachtelungen sind meistens nicht sehr gut lesbar.

[ Dieser Beitrag wurde am 17.11.2002 um 17:27 Uhr von Gregor editiert. ]

Ste.fun

Original erstellt von Gregor:
[quote]Original erstellt von Ste.fun:
[qb]Ich neige dazu Methoden extrem zu verschachteln

Ich versuche inzwischen, starke Verschachtelungen zu beseitigen bzw. zu umgehen. Verschachtelungen sind meistens nicht sehr gut lesbar.

[ Dieser Beitrag wurde am 17.11.2002 um 17:27 Uhr von Gregor editiert. ][/QB][/QUOTE]

Jep, stimmt. Ich versuche da imemr einen Kompromis zu finden. Entweder Verschachtelung, oder viele (unnötige) Codezeilen durch zusätzliche Instanzierungen - beides ist nicht so toll. Das eine wirkt der Lesbarkeit entgegen, das andere fördert das Scrollrädchen mehr.

Nochwas, bezüglich codeing standards:
Ich schreibe nie zwei anweisungen in eine Zeile! Das könnte man sonst zu schnell überlesen, finde ich.

Gregor

Was meinst du eigentlich mit "Methoden schachteln"? Ich verstehe nicht ganz, wie man so schnell auf die rechte Seite des Bildschirms kommt!

CengizS

@Gregor: Um hervorzuheben dass es etwas spezielles - eine Klasse - ist. Klar das sieht man auch am "class" aber wenn man innere Klassen etc hat und dann schnell drüberscrollt dann meint man oft es wären Methoden oder so. Deswegen hab ich mir das so angewöhnt.

Ste.fun

Original erstellt von Gregor:
Was meinst du eigentlich mit "Methoden schachteln"? Ich verstehe nicht ganz, wie man so schnell auf die rechte Seite des Bildschirms kommt!

Oh, hier habe ich dir ein kleines Beispiel, eben erst programmiert:

private boolean compareNewPassword()
{
  return String.valueOf(field_newPassword.getPassword()).equals(String.valueOf(field_retypePassword.getPassword()));
}

Das da oben ist bei mir so der Normalfall. Komme damit aber auch schon wieder über die 80 Zeichen

Ist eigentlich einfach zu lesen und zu verstehen, nur halt etwas zu lang...

[ Dieser Beitrag wurde am 17.11.2002 um 18:20 Uhr von Ste.fun editiert. ]

Gregor

Ach sowas meinst du!

Ich sehe, du schreibst da auch "field_". Markierst du so Membervariablen? Ich markiere die übrigens garnicht. ...meine Klassen sind meistens so klein, dass es offensichtlich ist, was eine Membervariable ist und was nicht (momentan durchschnittlich 53 Codezeilen / Klasse)

@ CengizS : Ach so! ...ich hatte mir das inzwischen schon durch etwas anderes erklärt. Bei Klassen kommt ja oft noch etwas hinter den Klassennamen : Z.B. ein extends oder ein implements. Ich hatte das darauf geschoben. Kommen "extends" und "implements" bei euch eigentlich in neue Zeilen, oder nicht? Bei mir nicht. ...dafür kommt bei mir jede öffnende geschweifte Klammer in eine neue Zeile.

Ste.fun

Diese field-Bezeichnung benutze ich nur bei Swing Komponenten. Sonst lasse ich diese immer weg. Ich schreibe diese Bezeichnung aber auch in Memberfunktionen. Beispiel:

private void halloPanel()
{
JPanel panel_hallo = new JPanel(new FlowLayout());
JLabel label_hallo = new JLabel("Hallo Welt!");
JButton button_hallo = new JButton("42");
//...
}

Diese Art der Bezeichnung hilft mir beim schnellen Wiederfinden der Variablen. Seit dem ich so arbeite komme ich mit der Variablenfülle viel besser klar

Membervariable markiere ich nie besonders. Sonst könnte ich ja gleich immer ein "this." als prefix benutzen, oder meinst du was anderes?

Gregor

Original erstellt von Ste.fun:
**
Membervariable markiere ich nie besonders. Sonst könnte ich ja gleich immer ein "this." als prefix benutzen, oder meinst du was anderes?**

Wenn ich C++ programmiere, dann kriegen Membervariablen bei mir immer ein "m_" davor. Finde ich aber nicht wirklich schön!

private void halloPanel()

Soetwas gibt es bei mir nicht. Methodennamen enthalten bei mir immer Verben. Dann ist es IMHO am klarsten, was die Methode macht. Es ist mindestens etwas in der Art, wie "get", "set", "init",... im Methodennamen enthalten. Meistens sind es natürlich andere Verben.!