Codequalitaet

[der JoJo]

Wenn ich das so lese, bin ich mir sicher das du nicht für Geld programmierst, und wenn doch, dann noch nicht lange...

zugegeben, ich programmiere erst seit 3 Jahren, aber ich beschäftige mich mit 3D Enginen entwicklung und kann daher sagen, das bei kleinen methoden die sehr häufig gerufen werden eine vorzeitige optimierung viel arbeit erspart.

 

[RicoSoft]

Mal so nebenbei: Wenn ich eine Methode habe, von der ich von vornhinein weiss, dass sie 20 Mio. mal aufgerufen wird, dann werd ich die ganz sicher optimieren. Man sollte Knuth nicht immer so schnell zitieren, ohne nicht auch seine ganzen Werke gelesen zu haben und dieses berühmte Zitat so frei im Raum stehen zu lassen.

Zurück zum Thema Codequalitaet: mir gefallen natürlich die ersten paar Zeilen um Welten besser, v.a. die korrigierte Version davon (vom Originalposter). Einfacher zu lesen, sehr einfach zu warten und definitiv sowieso unbrauchbar -- weil es dafür mit Sicherheit schon andere gibt, die das schon mal gemacht haben und man das folglich einfach von einer Library (auch die gigantische API der JDK muss man doch in der Zwischenzeit zu grossen Teilen als Library betrachten) reinnehmen kann.

Ich würde mehr Wert auf kurze, übersichtliche Klassen / Methoden legen, als darauf, alles auszucodieren. Auch sehr interessant ist sicherlich das definieren von pre-/post-conditions. Sowas kann man sehr schön kommentieren und mit Hilfe von Assertions oder ähnlichem sehr einfach überwachen.

Beim Codebeispiel 1 heisst es ja zum Beispiel, dass z nicht null sein kann, dann könnte man ja im Code ein

assert z != null

machen.

Und zu den gescheiterten Projekten anhand der Performance: Wenn die Projekte früher schon scheitern, dann wären sie vielleicht daran dann auch noch gescheitert. Man sollte nicht die Gründe für ein Scheitern nehmen, und sagen, dass sie darum an etwas anderem nicht gescheitert sind. Da wird eine Aussage umgekehrt, die so nicht umkehrbar ist. Man muss da sehr aufpassen. Die Projekte scheitern meistens zwar an Management und Terminproblemen anderer Art, aber sie kommen erst gar nie in ein Stadium, dass man so eine Aussage machen könnte.

 

[maki]

zugegeben, ich programmiere erst seit 3 Jahren, aber ich beschäftige mich mit 3D Enginen entwicklung und kann daher sagen, das bei kleinen methoden die sehr häufig gerufen werden eine vorzeitige optimierung viel arbeit erspart.

OK, im Bereich 3D ist Performance sehr wichtig, dafür werden manchmal sogar Darstellungsfehler in Kauf genommen, wie früher(immer noch?) zB. bei NVIDIA.

Für "normale" Anwendungen dagegen spielt es wirklich nur noch eine untergeordnete Rolle. Fachliche Fehler sind dagegen kaum verzeihbar, da hast du dann mal schnell ein richtiges Drama am Hals wenn's schlecht läuft.

 

[Marco13]

Naja. Es geht (mir) nicht um frühe (oder vorzeitige) Optmierungen. Und auch nicht darum, ob ein Programm nur 40 oder 60 Minuten braucht. Es geht auch nur bedingt um Performance. Es geht (und ich weiß, dass du das jetzt als Anlaß zur gegen-Kritik sehen wirst) nicht zuletzt ganz einfach ums Prinzip.

Diejenigen, die bestimmte (meintetwegen "akademsiche") Qualitätsansprüche an ihre Software stellen, werden mich verstehen. Diejenigen, die (im Gegensatz zu mir) ausschließlich in der freien Wirtschaft (d.h. für die Industrie) arbeiten, werden mich vielleicht auch verstehen, aber AUCH den anderen Standpunkt, dass man eben manchmal was Hacken (sorry: "besonders kurz schreiben") muss, um Zeitvorgaben einzuhalten (ob sich DAS in diesem Beispiel lohnt, ist eine andere Frage).

Bisher wissen wir nicht, wie groß die übergebenen Arrays sind. Wir können davon ausgehen, dass sie klein sind, und die Aufgabe lösen, indem wir 2 Zeilen code schreiben und "sort" verwenden. Oder wir können universell einsetzbaren, vorausschauenden, und (in bezug auf die Laufzeit) optimalen Code schreiben, indem wir eine simple Schleife verwenden. Wenn die Arrays klein sind, ist die Schleife nicht nachteilhaft, sondern bringt einen vernachlässigbaren Vorteil. Wenn die arrays groß sind, bringt die Schleife u.U. einen DEUTLICHEN Vorteil, und man erspart sich den einen oder anderen Profilerlauf....

Bestimmte Dinge sehe ich eben als selbstverständlich an. Dazu gehört dass man
1. nicht sinnlos (Arbeits)Zeit verschwendet, indem man "besonders optimierten" Code schreibt, der keinen Vorteil bringt
2. nicht sinnlos (Rechen)Zeit verschwendet, indem man den Rechner sinnlosen Müll berechnen läßt
Vielleicht werden die beiden Punkte (in der Industrie und im nicht-industriellen Bereich, aber auch von Person zu Person) unterschiedlich gewichtet. Aber ich würde die Minimumsuche ebenowenig über eine Sortierung lösen, wie etwa die Enthaltenseinsabfrage bei einem Array über "Arrays.asList(array).contains(objekt)". In beiden Fällen schreibt man eine Schleife, und gut ist.

Für "normale" Anwendungen dagegen spielt es wirklich nur noch eine untergeordnete Rolle. Fachliche Fehler sind dagegen kaum verzeihbar, da hast du dann mal schnell ein richtiges Drama am Hals wenn's schlecht läuft.

Fachliche Fehler? Zum Beispiel, wenn jemand diese praktische Funktion benutzt, um sich das minimale Element eines Arrays bestimmen zu lassen, und sich dann wundert, warum sein komplettes Programm nur Mist ausspuckt? Bis man herausgefunden hat, das so eine unverfängliche, triviale Funktion wie die Minimumsuche, die ja garantiert nur einmal durch den Array laufen muß, bewirkt, dass der übergebene Array nachher sortiert ist, kann eine Weile ins Land gehen, und die eine oder andere Deadline verstreichen.........

Fang' jetzt aber bitte nicht an mit array.clone() - dadurch wird es nicht besser, sondern noch schlechter.

 

[maki]

Bestimmte Dinge sehe ich eben als selbstverständlich an. Dazu gehört dass man
1. nicht sinnlos (Arbeits)Zeit verschwendet, indem man "besonders optimierten" Code schreibt, der keinen Vorteil bringt
2. nicht sinnlos (Rechen)Zeit verschwendet, indem man den Rechner sinnlosen Müll berechnen läßt

Beim ersten Punkt gebe ich dir Recht, beim zweiten bin ich der Meinung, das Rechenzeit nichts mehr kostet(speziell da Rechner sich die meiste Zeit nur lageweilen und auf Usereingaben warten), wenn's wirklich zu lange dauert, kann man immer noch optimieren.

Fachliche Fehler? Zum Beispiel, wenn jemand diese praktische Funktion benutzt, um sich das minimale Element eines Arrays bestimmen zu lassen, und sich dann wundert, warum sein komplettes Programm nur Mist ausspuckt? Bis man herausgefunden hat, das so eine unverfängliche, triviale Funktion wie die Minimumsuche, die ja garantiert nur einmal durch den Array laufen muß, bewirkt, dass der übergebene Array nachher sortiert ist, kann eine Weile ins Land gehen, und die eine oder andere Deadline verstreichen.........

Nun, das ist ein guter Grund den ich akzeptiere, ohne wenn und aber.