Hi Leute,

ich bin zwar nicht mal ganz so neu was das Programmieren, aber ich habs auch nur so ein bissi aus dem Info Unterricht gelernt und mach nächte Woche meine mündliche Abi Prüfung u.a. über Java.

Ich hab mich schon mit einigen Leuten übers Programmieren unterhalten und jeder meinte irgendwie "bevor du weiter codest leg dir erst mal ein anständigen Programmierstil zu, so sieht das doch nach nichts aus".

Aber irgendwie konnte oder wollte mir keiner sagen wie "guter Code" aussehen soll.

Vielleicht kann mir hier einer sagen wie ein guter Code von der Formatierung her aussehen soll?

Danke & Gruß

Lordk

Ein guter Programmierstiel sollte immer für andere gut lesbar sein.

Besorg die Quellcode und versuche den nachzuvollziehen. Gelingt es dir gut, ist der Programmierstiel gut. Merke dir die Merkmale, warum Du ihn gut lesen konntest.

Desweiteren solltest Du versuchen Recourssensparend zu programmieren.

Hi,

befolge die Standards die es in der Sprache, bzw. Firmenintern gibt. In Java ist der Standard z.B. Klassen und Packages fangen mit einem Großbuchstaben an, Methoden und Variabelen mit einem kleinen.

Die Methode sollte sprechend sein, so z.B. die get/set-Methoden. Hinzufügen/geben.

Wenn die Methoden einen Boolwert zurückgeben, dann beginnen diese mit is...

Dann sieht der Code schon sehr sauber aus.

Hallo,

das hier ist der Standard von SUN, wenn man sich an den hält hat man schon viele neue Freunde gewonnen ;-)

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

Original geschrieben von Irinius

Hi,

befolge die Standards die es in der Sprache, bzw. Firmenintern gibt. In Java ist der Standard z.B. Klassen und Packages fangen mit einem Großbuchstaben an, Methoden und Variabelen mit einem kleinen.

Also zumindst bei den Packages bin ich massiv einer anderen Meinung.

Der Standard bei Java ist das Packages klein und durchgängig klein geschrieben werden (keine Mixed-Types wie bei Methoden und Variablen).

Außerdem sollte man auch noch wissen, dass Konstanten normalerweise nur aus Großbuchstaben bestehen z.B. PI auch wenn dies nichtmal in der Java-API durchgängig so ist z.B. java.util.Color.

Zusätzlich ist eine häufige Normierung, dass keine Abkürzungen in Methoden, Variablen, etc benutzt werden sollen, da eine Abkürzung die für den Programmierer naheliegend ist, muss dies nicht für jeden anderen Programmierer sein.

Ich hab mich schon mit einigen Leuten übers Programmieren unterhalten und jeder meinte irgendwie "bevor du weiter codest leg dir erst mal ein anständigen Programmierstil zu, so sieht das doch nach nichts aus".

Aber irgendwie konnte oder wollte mir keiner sagen wie "guter Code" aussehen soll.

Das ist wohl auch so eine Sache, die jeder anders sieht - "guter Code" ist ja ziemlich subjektiv. Nimm alleine mal diese Beiden Variationen:

public static void main(String[] args) 

{

  for(int i=0; i < args; i++)

  {

    foo(args[i]);

  }

}

und

public static void main(String[] args)  {

  for(int i=0; i < args; i++) {

    foo(args[i]);

  }

}

Beide machen _exakt_ dasgleiche aber sehen doch von der Formatierung her anders aus. Ich fand mal das erste supertoll und das zweite grottenschlecht. Inzwischen hat sich das Blatt gewendet und Nr. 1 kann ich nicht mehr sehen *g* Gibt auch sowas hier (wird glaube ich bei GNU gerne so gesehen)

public static void main(String[] args)  

  {

  for(int i=0; i < args; i++) 

    {

    foo(args[i]);

    }

  }

Du siehst - alleine bei eigentlich simplen Sachen wie Einrückung prallen schon Welten aufeinander - und wir haben noch nicht einmal von Einzug geredet (wieviele Zeichen, Tabs oder keine Tabs etc.)

Es isit also (finde ich) gar nicht mal so wichtig _wie_genau_ dein Stil aussieht - Hauptsache ist, dass es einen Stil gibt, den man wiedererkennen kann und der es einem ermöglicht das Problem relativ schnell und einfach zu verstehen.

Ciao

Christian

was hier noch gar nicht erwähnt wurde: KOMMENTARE!!!

Nervig, sie zu schreiben, aber die gehören in jeden Code, der nochmal von einer weiteren Person nachvollzogen werden muss!!!

Wie sagte mal einer meiner Ausbilder: Nehme 2 Programmierer und du bekommst mind. 3 ProgStile.

Den Firmenstil übernehmen ist eine gute Idee. Generell bleibt es eine Sache von dir, überlege dir einfach verschiedene Dinge (Einrückungen, Kommentare, etc) , die du aber beibehalten musst ...

Matze

Zudm kann man gerade in Java mit guten Kommentaren mit dem Programm javadoc die halbe Dokumentation erstellen.

Infos unter: Javadoc Homepage

Übrigens: ein sehr gelungenes Buch zum Thema:

The elemets of java style von Allan Vermeulen.

Generell gilt meines erachtens, wenn man sich nahe an den Sun Java Style Guide hält ist man schon recht nehe an sauberen programmen. Über diverse Kleinigkeiten lässt sich Streiten und ist auch eher Geschmacksache (z.B. Klammerpositionierung von Blöcken usw).

Wichtig ist nur, dass alle Entwickler eines Projektes den gleichen Style Guide verwenden, sonst bringt jeder Style Guide nix, wenn jeder einen anderen nimmt

Ja vieles wurde heir schon genannt. auch ich möchte meine meinung hier von mir geben.

grundsätzlich ist es wichtig, dass andere programmierer bzw. leute sich schnell reinfinden können. d.h., dass dazu sowohl kommentare und auch ein übersichtlicher quelltext gehört.

wie hier schon festgestellt wurde, legt sich jeder früher oder später einen eigenen programmierstil zu. dieser sollte aber an die konventionen der programmiersprache (groß und kleinschreibung, z.b. von methoden, klassen,...) eingehalten werden.

ich habe mir relativ schnell angewöhnt die quelltexte mit einrückungen zu schreiben. dazu gehört eben auch, dass die geschweifte klammer auf eine neue zeile kommt. damit fallen fehler, wie "eine klammer vergessen", schneller auf.

für den JBuilder gibt es aber mittlerweile auch in diesem fehlerbeispiel abhilfe. mit einem plugin werden die zusammengehörigen klammern farbig hervorgehoben, wenn man mit dem cursor auf einer der beiden ist.

mfg.

TobiTobsen

Ich würde zum Stil, aber auch die Schnelligkeit des Programmes beachten.

Wenn du z.B.

if ( string.length() != 0 )

statt

if ( string != "" )

benutzt hast du schon wieder ziemlich an laufzeit gesparrt. Und von diesen Punkten gibts sicher noch ne ganze Menge, nur hab ich z.Zt. leider keine Liste hier.

Wenn du z.B.

if ( string.length() != 0 )

statt

if ( string != "" )

benutzt hast du schon wieder ziemlich an laufzeit gesparrt.

Meinst du wirklich? Im zweiten Falle vergleichst du ja nur zwei Referenzen miteinander, wogegen du im ersten Falle einen Methodenaufruf plus einen Vergleich hast. Ich hab's auch gerade mal durchgetestet mit

  String test = "eee";

  for(int j=0; j < 10; j++) {

  long start = System.currentTimeMillis();

  for(int i=0; i < 200000000; i++) {

//    boolean erg = (test == "");

    boolean erg = (test.length() == 0);

  }

  long end = System.currentTimeMillis();

  System.err.println("x: " + (end - start));

}

Die test == "" dauert pro Durchlauf ca. 800 ms, die test.length() == 0 dauert ca. 1200 ms.

Mal ganz nebenbei: Strings mit == zu vergleichen ist ohnehin nicht der Hit :-)

Ciao

Christian

Mal ganz nebenbei: Strings mit == zu vergleichen ist ohnehin nicht der Hit :-)

nicht der Hit ? ist sogar verboten ;-) und wenn der String einen NULL-Wert hat gibt's auch gleich kostenlos ne NPE dazu, daher mit .equals() arbeiten und den String auf die rechte Seite:

if (! "".equals(myString)) {

...

}

hier ist ein guter Link, sehr lesenswert:

http://www.ambysoft.com/javaCodingStandards.html

Original geschrieben von Felicie

was hier noch gar nicht erwähnt wurde: KOMMENTARE!!!

Nervig, sie zu schreiben, aber die gehören in jeden Code, der nochmal von einer weiteren Person nachvollzogen werden muss!!!

Vielleicht liege ich ja falsch, aber wenn man für alles Kommentare benötigt, damit es irgendwann nochmal nachvollzogen werden kann, dann sollte man überlegen, ob man den Code nicht klar genug geschreiben hat, ob der Code nicht das ausdrückst, was es tut.

Ist das der Fall sollte man den Code noch mal überarbeiten.

Kommentare sollten dort verwendet werden, wo sie etwas klären, wenn auch aus einem klar geschriebenen Code nicht ersichtlich ist, was er tut. Aber so häufig gelesene Kommentare wie "hier wird x der Wert 10 zugewiesen" vor einer Ausweitung "x = 10;" sind unsinnig und hinderlich.