Original geschrieben von KoMtuR
Natürlich ist das schwer zu erklären. Jeder hat einen eigenen "Standard". Du hältst vielleicht ein Code für gut und ich wiederrum meine, dass ich ihne sch... finde. Ich denke einfach mal, dass er mit gutem code meint, dass er erstens fehlerfrei gesciptet wird und dann auch keine Angriffsmöglichkeiten bilden. Man sagt ja auch immer, dass man einen Code so schreiben sollte, dass jeder dieses Stück lesen kann.
Aber lesen können wir alle und wer sich ein Codestückchen anschaut und verstehen will, muss sich ja auch zwangsläufig mit der Sprache auskennen. Ich kann ja nicht alle kommentieren, am Besten noch die Definition am Ende rankommentiert.
Ist glaub ich fast so, wie wenn du fragen würdest, was der Unterschied von "das Gleiche" und "das Selbe" ist 
Original geschrieben von Nils Hitze
Code den ein mit der Applikation unerfahrener Benutzer in einer vernünftigen
Zeitspanne verstehen und bearbeiten kann.
Da muss ich dir widersprechen Nils. Ein unerfahrener Programmierer sollte etwas an seiner Erfahrung arbeiten wenn dies zum Problem wird.
Streichst du das Unerfahren dann unterschreib ich dir den Satz.
Wartbarkeit, heisst u.a das die Logic die in dem Code steckt, von 3. Programmierern nachvollzogen werden kann
Original geschrieben von Nils Hitze
Nachdem ich gerade (wieder mal) an Code sitze bei dem ich alle
zwei Zeilen entweder weinen oder lachen könnte und das schon
öfter machen musste geht vernünftig kommentierter Code mit
einer übersichtlichen Struktur und klar erkennbaren Funktionen für
mich über alles.
Soll ich dich an Rolands Code errinnern (Gott sei dank, hab ich damit
nichts mehr zu tun) ?
Original geschrieben von Wolfsbein
7. Er muss wiederverwendbar sein. Der Programmierer an sich ist faul .
Ja wenn die Wiederverwendbarkeit nicht mit zu hohen Entwicklugsaufwand erkauft wird.
Wenn ich etwas für eine Firma entwickel die ihre komplett eigenen Geschäftsprozesse haben, ist es eher Schädlich auf Teufel komm raus das so umzugestallten das ich so viel wie möglich davon wieder benutzen kann.
Wir als Endprogrammierer (diejenigen die aus Librarys und SDK fertige Programme kreairen) brauchen diese Wiederverwendbarkeit nicht ins Extreme zu treiben.
Das heisst die Wiederverwendbarkeit ist je nach Art des Produktes wichtig. Schreiben wir eine GUI Applikation für einen Kunden ist sie weniger wichtig als wenn wir ein Framework für dies oder jenes schreiben.
Original geschrieben von squeaker
Guter Code ist der Code, der a) seine Aufgabe erfüllt und b) von jemand fremdem gelesen werden kann und er danach grob versteht, wass der Code macht.
Bubblesort kann auch "guter Code" sein - wenn nicht viel zu sortieren ist, z.B.
Zum 1. Satz: unterschreib
Zum 2. Satz: weshalb sollte ich ein Bubblesort implementieren wenn ich anhand meines eigenen Comporators und einer sort Methode sortieren kann?
Der Comporator hat einen riesen Vorteil vor jeder eigenen Implementierung, jeder Java Programmierer erkennt gleich wonach sotiert wird und muss sich nicht erst in die Implementierung der Sotierung einarbeiten.
Zu Klammern und ähnlichem:
Absolut sekundär.
Ein programmierer kann sämmtliche Arten von Klammerung lesen, solange dies nicht auf die Spitze getrieben wird.
Guter Code ist bei OOP Code ein sinnvolles Object Orientiertes Design.
Und genau das ist etwas das den meisten Anfängern auch fehlt. Denn das feeling dafür wie mann am besten Kapselt kommt erst mit der Zeit.
Guter Code versucht mehr zu sein als er ist. Sprich selbst wenn das Ziel
eine Applikation in Deutsch, und nur in Deutsch ist, versucht guter Code schon vorrauszusehen das die Applikation irgendwann internationalisiert wird und sorgt dafür das keine Strings im Code selber stehen. Auch sorgt guter Code dafür das es einfach ist Funktionalität durch einfaches Austauschen / Hinzufügen von Klassen ermöglicht wird.
Guter Code zeigt das der Programmierer nicht sein Ego befriedigen wollte, in dem er dem Code seine "Persöhnliche Handschrift" aufträngt sondern er hält sich an allgemein gültiges. Er ist so einfach wie möglich gestrickt und verzichtet darauf Komplexität hinzuzufügen ohne einen wirklichen zugewinn.
Guter Code versucht es zu vermeiden x Schleifen ineinanderzuquetschen und hier einen Trigger und da einen zu setzen nur das früher oder später das gewünschte Ergebnis zu stande kommt, sondern er ist ausreichend Modularisiert das die Methoden / Funktionen klein sind und nur ihre beschreibende Aufgabe durchführen.
Guter Code verlässt sich nicht darauf das alles glatt geht, sondern er hat für alles einen Plan B. Das heisst ein Code der Daten aus einer Datenbank liest, daraus ein PDF generiert und dieses per SOAP Call an ein Webservice als Bytearray schickt weiss wie er regieren muss.
So gibt es Datenbanken die nur eine bestimmte Menge an gleichzeitigen Verbindungen erlauben, guter Code reagiert auf sowas indem er sich einen Timeout gibt die Verbindung versucht aufzubauen, wenn dieses nicht funktioniert eine Pause macht, es erneut versucht und am ende des Timeouts richtig reagiert (Logging? Error Mail an den Admin?) er reagiert auch darauf wenn das PDF generieren und speichern des PDFs nicht möglich ist (Festplatte voll?!) und hat ebenso eine Fehlerbehandlungsroutine für den Fall das der Webservice nicht erreichbar ist.
Diese Fehlerbehandlung ist etwas das ich hier im Forum bei den meisten als nicht durchgeführt sehe.
So werden Daten auf die Festplatte geschrieben, ohne das sich jemand Gedanken macht was passiert wenn die Platte voll ist? Das Programm ohne sinnvolle Behandlung einfach abstürzen zu lassen, hat wenig Sinn und hat mit gutem Code nix zu tun.
Und guter Code ist es, wenn er nicht so aussieht wie der Code den ich noch vor einem Jahr geschrieben habe
