Einfacher Coder == guter Code?

sümple schrieb:

Kann man sagen, dass Code der einfacher zu lesen und verstehen ist auch (fast) immer besser ist?

Zusammen mit dem (fast) kann ich das unterschreiben.

Andromeda

sümple schrieb:

Kann man sagen, dass Code der einfacher zu lesen und verstehen ist auch (fast) immer besser ist?

Besser in welcher Beziehung?
So ein Code ist besser zu Warten und zu Erweitern, aber sonst?
Es gibt Codes, die extrem auf Geschwindigkeit optimiert sind und die kann man kaum lesen. Jedenfalls nicht, wenn nicht alle 2 Zeilen ein Kommentar steht.

Blue-Tiger

sümple schrieb:

Kann man sagen, dass Code der einfacher zu lesen und verstehen ist auch (fast) immer besser ist?

Nein, denn "einfach zu lesen" ist sehr subjektiv. Code, den einige "elegant & einfach" nennen wuerden, ist fuer andere (z. B. Leute, die die Sprache nicht so gut kennen) schrecklich unverstaendlich:

// KOMPLIZIERT: je nach Parameter ruf ich Funktion A, B, C, D, E, F ... oder Z auf:
void dispatchWork(int param)
{
    switch (param)
    {
        case 0: a(); break;
        case 1: b(); break;
        // ...
    }
}
dispatchWork(getResultOfSomeFunction());

// EINFACH: ich hab ein Array aus Funktionspointern.
(*dispatcherArray[getResultOfSomeFunction()])();

Anderer Code, den einige "einfach und leicht zu verstehen" nennen wuerden, wirkt auf andere einfach "umstaendlich und haesslich"

// EINFACH: summiere die Einkommen der Jeweiligen Monate
int yearSum = sumJanuary + sumFebruary + sumMarch + sumApril + sumMay + ... + sumDecember;

// KOMPLIZIERT: benutze ein Array:
int yearSum = 0;
for (int i = 0; i < 12; ++i)
    yearSum += monthSum[i];

Das sind jetzt Baby-Beispiele, aber z. B. loesen Leute, die sich mit Template-Programmierung auskennen, ihre Probleme gern damit, weil damit meist "einfache" Problemloesungen zustande kommen koennen. Aber wer Templates nicht vestanden hat, wird auch den Code nicht oder nur sehr schwer verstehen.

Es kommt auf den Standpunkt und das eigene Wissen drauf an. Man kann Code in der Regel vereinfachen, indem man vom konkreten Problem abstrahiert. Andrerseits erreicht man irgendwann den Punkt, do die Abstraktion selbst wesentlich schwerer zu verstehn ist als das eigentliche Problem.

Andromeda schrieb:

sümple schrieb:

Kann man sagen, dass Code der einfacher zu lesen und verstehen ist auch (fast) immer besser ist?

Besser in welcher Beziehung?
So ein Code ist besser zu Warten und zu Erweitern, aber sonst?
Es gibt Codes, die extrem auf Geschwindigkeit optimiert sind und die kann man kaum lesen. Jedenfalls nicht, wenn nicht alle 2 Zeilen ein Kommentar steht.

Dieser extem optimierte Code ist mir noch nie begegnet (könnte bei Assembler Code sein, aber gehen mir mal von höheren Programmiersprachen aus). Alles was ich bisher an zu langsamem Code gesehen hab, war schlecht durchdacht und zu kompliziert und deshalb langsam.

Blue-Tiger schrieb:

Nein, denn "einfach zu lesen" ist sehr subjektiv. Code, den einige "elegant & einfach" nennen wuerden, ist fuer andere (z. B. Leute, die die Sprache nicht so gut kennen) schrecklich unverstaendlich:

...

Das sind jetzt Baby-Beispiele, aber z. B. loesen Leute, die sich mit Template-Programmierung auskennen, ihre Probleme gern damit, weil damit meist "einfache" Problemloesungen zustande kommen koennen. Aber wer Templates nicht vestanden hat, wird auch den Code nicht oder nur sehr schwer verstehen.

Es kommt auf den Standpunkt und das eigene Wissen drauf an. Man kann Code in der Regel vereinfachen, indem man vom konkreten Problem abstrahiert. Andrerseits erreicht man irgendwann den Punkt, do die Abstraktion selbst wesentlich schwerer zu verstehn ist als das eigentliche Problem.

Geh mal davon aus, dass der der den Code schreibt auch die Sprache kann. Ein Array aufsummieren ist nicht komplizierter, als alles einzeln hinzuschreiben. unter einfachem Code wird wohl keiner Code verstehen, der so geschrieben ist, wie ihn ein Anfänger schreiben würde.

sümple schrieb:

Geh mal davon aus, dass der der den Code schreibt auch die Sprache kann.

Das ist so ziemlich die falscheste Annahme schlechthin. Ich würde sogar behaupten das 80% der (heutigen) "Programmierer" die Sprache (in der sie gerade arbeiten) nicht mal annähernd kennen.

Ich behaupte mal das man eine Sprache erst "kennt" wenn man mindestens 80% der Sprachfeatures begriffen hat.

Hinzu kommt das viele Programmierer auch Sprachfeatures benutzen die sie nichtmal selber verstehen, weil sie sie einfach von irgendwo anders kopiert haben und sich damit zufrieden geben das das Ergebnis ungefähr dem entspricht was sie erreichen wollten. (Anti-Pattern Copy-Paste Programmierung).

Also davon auszugehen das jemand der Code schreibt auch die Sprache kennt ist absolut Realitätsfremd...

Heinzelotto

loks schrieb:

Das ist so ziemlich die falscheste Annahme schlechthin. Ich würde sogar behaupten das 80% der (heutigen) "Programmierer" die Sprache (in der sie gerade arbeiten) nicht mal annähernd kennen.

Ich behaupte mal das man eine Sprache erst "kennt" wenn man mindestens 80% der Sprachfeatures begriffen hat.

er hat nicht von "kennen" sondern von "können" gesprochen. Und ich glaube mit "können" hat er auch nicht gemeint, dass die betreffende Person die Sprache vollständig bis ins letzte detail beherrscht.

Walli

sümple schrieb:

Andromeda schrieb:

sümple schrieb:

Kann man sagen, dass Code der einfacher zu lesen und verstehen ist auch (fast) immer besser ist?

Besser in welcher Beziehung?
So ein Code ist besser zu Warten und zu Erweitern, aber sonst?
Es gibt Codes, die extrem auf Geschwindigkeit optimiert sind und die kann man kaum lesen. Jedenfalls nicht, wenn nicht alle 2 Zeilen ein Kommentar steht.

Dieser extem optimierte Code ist mir noch nie begegnet (könnte bei Assembler Code sein, aber gehen mir mal von höheren Programmiersprachen aus). Alles was ich bisher an zu langsamem Code gesehen hab, war schlecht durchdacht und zu kompliziert und deshalb langsam.

Gerade bei numerischen Berechnungen kann zu viel Abstraktion manchmal einen Overhead erzeugen. Wenn man z.B. nur begrenzte Rechenzeit auf einem Cluster hat, dann nimmt man lieber schwer verständlichen Code, der u.U. doppelt so schnell ist. Ich hatte neulich noch ein Beispiel aus der numerischen Strömungsmechanik. Mein Löser war mit boost::numeric::ublas und einigem an Abstraktion realisiert und ein Code, der einem Buch beilag, war einfach runter programmiert und arbeitete auf C-Arrays. Ich war zunächst etwa um den Faktor 2 langsamer und konnte mit ein wenig Tuning auf ca. 1.4 kommen. Das sind auf komplexe Simulationen übertragen immer noch mehrere Stunden Rechenzeit vergeudet.

Shade Of Mine

also in meiner erfahrung ist ein besserer/anderer algorithmus sinnvoller als mikrooptimierung. und in den ganz ganz ganz ganz ganz ganz seltenen faellen wo mikrooptimierung sinn macht, tja - in so eine situation kommen die aller wenigsten.

deshalb: einfacher code fuehrt fast immer zu besserem code.

Walli schrieb:

Gerade bei numerischen Berechnungen kann zu viel Abstraktion manchmal einen Overhead erzeugen. Wenn man z.B. nur begrenzte Rechenzeit auf einem Cluster hat, dann nimmt man lieber schwer verständlichen Code, der u.U. doppelt so schnell ist. Ich hatte neulich noch ein Beispiel aus der numerischen Strömungsmechanik. Mein Löser war mit boost::numeric::ublas und einigem an Abstraktion realisiert und ein Code, der einem Buch beilag, war einfach runter programmiert und arbeitete auf C-Arrays. Ich war zunächst etwa um den Faktor 2 langsamer und konnte mit ein wenig Tuning auf ca. 1.4 kommen. Das sind auf komplexe Simulationen übertragen immer noch mehrere Stunden Rechenzeit vergeudet.

Warum ist ein Code der eine numerische Berchnung ausführt, jetzt einfacher, wenn er viel Abstraktion enthält?

Walli

sümple schrieb:

Warum ist ein Code der eine numerische Berchnung ausführt, jetzt einfacher, wenn er viel Abstraktion enthält?

Weil man quasi die Vorgehensweise aus dem Mathebuch eins zu eins runterschreiben kann. Nur manchmal ist das nicht so schön. Zum Beispiel wenn da irgendwo im Pseudocode steht $\vec{x} \leftarrow \vec x + \alpha\cdot\vec{e}_i$ habe ich zwei Möglichkeiten:

x += a * UnitVector(i)
x[i] += a

Bei 1) muss ich mich drauf verlassen, dass der Optimizer schlau genug und die Implementierung von UnitVector gut genug ist, dass in beiden Fällen annähernd gleich schneller Code erzeugt ist. Das Beispiel ist vielleicht nicht so glücklich gewählt, weil ich vermute, dass man das hinreichend gut optimieren kann und weil 2) nicht wesentlich schwerer zu lesen ist als 1). Trotzdem gibt es Fälle, wo man auf Kosten der Lesbarkeit lieber direkt an den Daten fummelt.

rapso

Shade Of Mine schrieb:

also in meiner erfahrung ist ein besserer/anderer algorithmus sinnvoller als mikrooptimierung. und in den ganz ganz ganz ganz ganz ganz seltenen faellen wo mikrooptimierung sinn macht, tja - in so eine situation kommen die aller wenigsten.

Das würde ich so auch unterschreiben.
1.) die meisten schaffen es nichtmal einen profiler vorher anzuwerfen um die kritischen stellen herauszufinden, sondern legen aufgrund von ihren "Logischen" ueberlegungn los. manchmal bringt es ein paar %, oder das doppelte oder... aber oft weiss man nicht wie weit man vom optimum ist und wo das problem liegt.
2.)x86 prozessoren werden dahin optimiert schlechten code schnell auszufuehren. und das ist die plattform die die meisten verwenden. wenn man sich 08/15 code auf konsolen oder servern (mit z.b. PowerPC) anschaut, sieht man oft dass da lauter hazards und sonstige dinge sind die kein optimizer wegoptimieren DARF.
3.) haben programme oft weit mehr probleme als schnell zu sein, das sollte man erstmal in den griff bekommen.

deshalb: einfacher code fuehrt fast immer zu besserem code.

da wuerde ich das gegenteil behaupten. der wenigste einfache code ist schnell, es ist eher der aufwendige code mit dem man zum ziel kommt und der trotzdem dem compiler sagt wie er es schnell zu machen hat.

Shade Of Mine

rapso schrieb:

da wuerde ich das gegenteil behaupten. der wenigste einfache code ist schnell, es ist eher der aufwendige code mit dem man zum ziel kommt und der trotzdem dem compiler sagt wie er es schnell zu machen hat.

Ich denke wir meinen schon das selbe, nur ist "einfach" ein etwas doofes wort.

ich meine damit eher code der nicht versucht uebermaessig clever zu sein. aber dennoch soll der code nicht "dumm" sein. beispiel: fuer ein switch mit strings koennte man ganz viele if-else ifs machen -> das waere uU das "einfachste". Das sinnvolle waere einfach eine standard map zu nehmen (nicht zwangslaeufig std::map), das zu clevere waere wohl zu versuchen das ganze selber zu hashen ohne eine hashmap oder aehnliches zu verwenden.

nicht ideal das beispiel, aber uU reicht es als erklaerung was ich meine.

sümple schrieb:

Kann man sagen, dass Code der einfacher zu lesen und verstehen ist auch (fast) immer besser ist?

kurze antwort: ja!

je einfacher code zu verstehen ist, desto wartbarer ist er. schlecht wartbarer code ist schlechter code. nicht wartbarer code ist unbrauchbarer code.

muemmel

Hi,

stimme da auch zu. Code der einfach gehalten ist hat größere Chancen wenige Fehler zu enthalten als Frickelcode.
Auch sid vermutlich einfache Codefragmente für den Compiler wesentlich leichter und besser zu optimieren als complizierte.
Bei den heutigen Prozessorgeschwindigkeiten ist das Tempo (meist) nicht mehr das absolute Primat. Aber stimmen sollte das was rauskommt immer noch. Die Problemstellungen werden heute in vielen Fällen wesentlich komplizierter als früher, und Zeit bei der Entwicklung hat auch keiner zu verschenken. also muß der Code in erster Linie nicht für Herrn Compiler, sondern für die Menschen die ihn lesen/an ihm arbeiten gestrickt werden. Wenns dann wirklich nicht reicht kann man immer noch gezielt die wirklichen Hemmschuhe beseitigen.
Ich hab selber mal was mit Grafik auf nem 386er ohne Copro gemacht, für den war schon ein einfacher Vorzeichenwechsel oder Vorzeichentest eine Riesenaufgabe. Hab ich dann die Fortran-Singnum-Funktion sowie Abs... unter C mit Bitoperatoren nachgebildet. Hat funktioniert und wirklich in dem Fall sehr viel gebracht, aber aus dem Code schlussfolgern wollen wie der Algorythmus ist...
Ich hab da lieber die originale C-Version noch als Kommentar drangehängt.
Im übrigen finde ich Stroustrups Aufforderung gut, Kommentare knackig zu halten. In manchen Musterbeispielen sieht man vor lauter Kommentar den eigentlichen Quelltext gar nicht mehr.

Gruß Mümmel