Was ist für euch guter Programmcode?

[BloodLord]

Ich denke, man kann einen guten Programmcode daran erkennen, dass man beim überfliegen die Funktion und Funktionsweise des Programms erkennen kann.

Der Code sollte strukturiert und nicht zusammengepackt wirken. Die einzelnen Funktionen sollten kurz kommentiert sein, die Aufgabe der Funktion und deren Parameter beschrieben. Variablen- und Funktionsnamen sollten aussagekräftig sein, z.B.

int multiply(int a, int b) {

    return a*b;

    /* Multipliziert zwei Integer miteinander und liefert als Produkt wiederum
       einen Intger zurück. Dabei ist a der Multiplikand und b der Multiplikator */

}

Zugegeben das Beispiel ist ziemlich schlecht und ich bin auch nicht gut im Kommentieren aber man sollte eben verstehn worum es geht.

//EDIT Tippfehler...

[Gregor]

Frage 1337 schrieb:

Was macht für euch guten Programmcode aus?

- wenig Redundanz
- relativ kurze Methoden
- aussagekräftige Variablennamen usw.
- ausgiebige Nutzung der Standardbibliothek (man soll sich keine eigene Liste schreiben, wenn es in der Standardbibliothek schon eine gibt)
- defensiver Programmierstil
- Verwendung üblicher Entwurfsmuster, wo diese Sinn machen
- Verwendung jedes sinnvollen Sprachmittels (der Code soll nicht unnötig kompliziert sein, weil sich der Programmierer nicht gut genug mit der Sprache auskennt)

[Gregor]

BloodLord schrieb:

/* Dabei ist a der Multiplikand und b der Multiplikator */

Dieser Kommentar deutet darauf hin, dass die Variablennamen hier vielleicht doch nicht so aussagekräftig waren, wie sie sein sollten.

Abgesehen davon ist hier der gesamte Kommentar komplett überflüssig, da trivial. Der geht ja schon in die Richtung

a++; //increment a by 1.

[SirLant]

Vielleicht schon etwas OT, aber welche der folgenden Formen bevorzugt ihr

//Variante 1
Foo foobar (Foo, Bar);
//Anwendung
Foo foo (foobar (Foo(), Bar());

//Variante 2
Foo foobar( Foo, Bar );
//Anwedung
Foo foo( foobar( Foo(), Bar() );

Geht hier wirklich nur um die Setzung der Klammern.

[Shade Of Mine]

Optimizer schrieb:

hmmmmmmm schrieb:

see: http://geileseite.de

roflmao.

Bo ey.
Das hätte ich mir jetzt nicht gedacht...

muss mir merken "geileseite.de" ist keine gute beispiel URL

asdrubael schrieb:

Wichtig ist mir nicht WIE etwas gemacht wird sondern WAS.

Ich finde WIE und WARUM wichtiger als WAS. Denn WAS kann man am Namen der Funktion erkennen. WIE etwas und WARUM es so gelöst wurde, finde ich dagegen recht interessant. zB
//algo: BubbleSort
//reason: performance improvement: vec shouldn't not more than 12 values

finde ich besser als
//sorts a vector
void sort(vector<int>& vec);

SirLant schrieb:

Vielleicht schon etwas OT, aber welche der folgenden Formen bevorzugt ihr

Garkeins:

Foo foobar(Foo, Bar);
Foo foo(foobar(Foo(), Bar()));

[asdrubael]

Shade Of Mine schrieb:

asdrubael schrieb:

Wichtig ist mir nicht WIE etwas gemacht wird sondern WAS.

Ich finde WIE und WARUM wichtiger als WAS. Denn WAS kann man am Namen der Funktion erkennen. WIE etwas und WARUM es so gelöst wurde, finde ich dagegen recht interessant. zB
//algo: BubbleSort
//reason: performance improvement: vec shouldn't not more than 12 values

finde ich besser als
//sorts a vector
void sort(vector<int>& vec);

Das kommt halt drauf an ob man den sort nur benutzen möchte oder man davon getrieben wird genau zu verstehen was da überhaupt gemacht wird. Manche Leute fahren Auto ohne sich dafür zu interessieren wie das alles funktioniert und andere müssen alles auseinander bauen, analysieren und tunen. Ich neige dazu mich nicht für Dinge zu interessieren die funktionieren. Erst wenn das Ding zu langsam ist wird wichtig welcher Sort da verwendet wird und warum überhaupt genau dieser.

Ich bevorzuge übrigens Variante 1, aber sowas geht viel zu sehr in´s Detail. Das einzige was ich bei fremdem Code schlimm fände wäre wenn er alle drei Varianten durchmischt.

[Shade Of Mine]

asdrubael schrieb:

Das kommt halt drauf an ob man den sort nur benutzen möchte oder man davon getrieben wird genau zu verstehen was da überhaupt gemacht wird.

Wie würdest du denn eine Funktion sort() kommentieren?
wenn überhaupt würde ich den algo erwähnen, uU ein verweis auf eine erklärung des algos (falls griffbereit, zB weil ich den algo von dort habe) und eventuell ein grund warum dieser algo (falls es nicht ersichtlich ist oder genau dieser algo wesentlich besser als andere ist).

das WAS sollte IMHO aus dem code hervorgehen.

[Sascha2]

Gregor schrieb:

- defensiver Programmierstil

Was ist ein defensiver Programmierstil?
Was soll ich darunter verstehen?

[Sascha2]

BloodLord schrieb:

Ich denke, man kann einen guten Programmcode daran erkennen, dass man beim überfliegen die Funktion und Funktionsweise des Programms erkennen kann.

Der Code sollte strukturiert und nicht zusammengepackt wirken. Die einzelnen Funktionen sollten kurz kommentiert sein, die Aufgabe der Funktion und deren Parameter beschrieben. Variablen- und Funktionsnamen sollten aussagekräftig sein, z.B.

int multiply(int a, int b) {

    return a*b;

    /* Multipliziert zwei Integer miteinander und liefert als Produkt wiederum
       einen Intger zurück. Dabei ist a der Multiplikand und b der Multiplikator */

}

Zugegeben das Beispiel ist ziemlich schlecht und ich bin auch nicht gut im Kommentieren aber man sollte eben verstehn worum es geht.

//EDIT Tippfehler...

Besser wäre:

int multiply(int multiplikand, int multiplikator) {

    return multiplikand * multiplikator;

    /* Return liefert das Ergebnis der Multiplikation beider Operanden */

Das ein Integer zurückgeliefert wird, ist anhand der Funktionsdefinition ersichtlich.

[Matthias Lange|Work]

Gregor schrieb:

- defensiver Programmierstil

Was ist das?

[Helium]

//algo: BubbleSort
//reason: performance improvement: vec shouldn't not more than 12 values

Das Konstrukt "shouldn't not" ist auf jeden Fall interessant, sagt mit aber nichts.

Definiere, was ist für dich sauberes Design?

Beispiele?

In der Praxis wirst du sowas wohl nicht finden.

Also ich finde mein neues VST-Plugin ist von vorne bis hinten durchgehend verdammt sauber designed und außerdem ist es auch noch verdammt schnell und bis jetzt scheint es absolut Bug-frei zu sein (Version 0.02!), zumindest hat bisher keiner der (freiwilligen) Beta-Tester etwas negatives gesagt (im Gegenteil). Gut, das Projekt ist allerdings auch kein Riesen-Projekt, sondern besteht bisher aus etwa 40 Modulen und 50 Headern.

Ach ja, Eigenlob stinkt

[Download?]

Kann man das downloaden (Source)?

[Sascha2]

SirLant schrieb:

Vielleicht schon etwas OT, aber welche der folgenden Formen bevorzugt ihr

//Variante 1
Foo foobar (Foo, Bar);
//Anwendung
Foo foo (foobar (Foo(), Bar());

//Variante 2
Foo foobar( Foo, Bar );
//Anwedung
Foo foo( foobar( Foo(), Bar() );

Geht hier wirklich nur um die Setzung der Klammern.

Keine von beidem.

Die gefällt mir besser:

[cpp]
// Variante 3
Foo foobar (Foo, Bar);

//Anwendung
Foo foo (foobar (Foo(), Bar() );
[/cpp}

Bei mehreren Klammern hintereinander, sieht diese Variante einfacher aus.

Das diese aber nicht konsequent ist, ist mir auch klar,
hier hängt das also ganz von der Situation ab.

Variante 1 ist übrigens auch nicht konsequent.
Denn dazu müßte sie so aussehen:
[cpp]
//Variante 1 - KORRIGIERTE Fassung
Foo foobar (Foo, Bar);
//Anwendung
Foo foo (foobar (Foo (), Bar ());
[/cpp}

Konsequent ist also nur Variante 2.

[volkard]

Helium schrieb:

//algo: BubbleSort
//reason: performance improvement: vec shouldn't not more than 12 values

Das Konstrukt "shouldn't not" ist auf jeden Fall interessant, sagt mit aber nichts.

aber nur weil du so inflexibel und keine sätze ohne prädikat!

[Sascha2]

Mist, jetzt war die Klammer falsch, hier nochmal beide Varianten:

// Variante 3
Foo foobar (Foo, Bar);

//Anwendung
Foo foo (foobar (Foo(), Bar() );

//Variante 1 - KORRIGIERTE Fassung
Foo foobar (Foo, Bar);
//Anwendung
Foo foo (foobar (Foo (), Bar ());

[Helium]

Kann man das downloaden (Source)?

Nö. Es ist ja nicht alles Open Source.

[Download?]

Dann lass auch das Angeben sein.

[Gregor]

Matthias Lange|Work schrieb:

Gregor schrieb:

- defensiver Programmierstil

Was ist das?

Ich verseteh darunter ein gesundes Mißtrauen den anderen gegenüber, welches sich im Code widerspiegelt. Mit den anderen sind die Nutzer deines Codes gemeint, was auch du sein kannst. Man sollte den Code bespielsweise so schreiben, dass Fehler, die von anderen bei der Benutzung des Codes begangen werden schnell auffallen. Das heißt, dass man Parameter auf ihre Gültigkeit überprüft und nicht einfach nach irgendwohin weiterreicht oder mit ihnen rechnet: Wenn du in einem Setter die Gültigkeit des Parameters nicht überprüfst und die Membervariable einfach so auf den gegebenen Wert setzt, dann brauchst du dich nicht zu wundern, wenn irgendwo im Programm ein Fehler auftaucht, den du dir nicht erklären kannst. Defensiver Programmierstil beschränkt sich aber natürlich nicht auf Fehlerchecks, sondern kann auch andere Aspekte beinhalten. Beispielsweise kann es manchmal sinnvoll sein, Kopien von Parametern oder Rückgabewerten anzulegen, damit nicht plötzlich jemand unbeabsichtig außerhalb des Objekts dieses verändert. Weiterhin gehört ein sinnvolles Exception Handling natürlich auch zu einem defensiven Programmierstil. ...und so weiter. Grob gesagt heißt defensiver Programmierstil "so programmieren, dass möglichst wenig Bugs entstehen und, dass Bugs möglichst schnell erkannt und gefunden werden können".

[rüdiger]

Ja, ein defensiver Programmierstil ist wichtig. Da versuch ich auch drauf zu achten. Es erspart einem unmengen an Arbeit, wenn man Fehler entweder gleich vermeiden kann oder sie sich relativ schnell zur Wort melden.

[Helium]

@Download?: Nur weil nicht jeder den Code sehen darf, heißt es ja nicht, dass es niemand darf. Ich käme nie auf die Idee zu sagen: Hey, mein Code ist der beste.