Was ist für euch guter Programmcode?

Tjaja Shade, jetzt ist es raus

Helium schrieb:

Was macht für euch guten Programmcode aus?

Sauberes Design, gute Wartbarkeit.

Definiere, was ist für dich sauberes Design?

Beispiele?

hmmmmmmm schrieb:

see: http://geileseite.de

roflmao.

Frage 1337 schrieb:

Helium schrieb:

Was macht für euch guten Programmcode aus?

Sauberes Design, gute Wartbarkeit.

Definiere, was ist für dich sauberes Design?

Beispiele?

In der Praxis wirst du sowas wohl nicht finden.

asdrubael

Frage 1337 schrieb:

Was macht für euch guten Programmcode aus?

Selbsterklärender Code da wo es möglich ist, Kommentare wo nicht. Wichtig ist mir nicht WIE etwas gemacht wird sondern WAS. Dazu nötig sind aussagekräftige Namen für Variablen, Funktionen, Klassen etc. Niemand weiß was eine Variable nTemp tut oder eine Funktion Calculate(). Trivialitäten sollten nicht kommentiert werden, dafür so Sachen wie am Anfang der Datei eine Auflistung was das Programm tut, wer es geschrieben hat und wann.

Wichtig ist auch konsistenter Programmierstil. Also wenn ich mich z. B. dafür entscheide ungarische Notation zu verwenden sollte ich das immer tun und nicht manchmal so und manchmal so. Inkonsistenter Code ist schwieriger zu lesen als der schlechteste Standard.

Walli

Optimizer schrieb:

hmmmmmmm schrieb:

see: http://geileseite.de

roflmao.

Irgendwo muss er sich doch Inspiration holen .

Walli

asdrubael schrieb:

ungarische Notation

Bäh!

asdrubael

MaSTaH schrieb:

asdrubael schrieb:

ungarische Notation

Bäh!

Oder [hierMaSTaHsLieblingsCodingStandardeinsetzen]

SirLant

Ich finde nen Kommentar darf schon sein, so ist eine Funktion savegame() sicher selbsterklärend vom Sinn her, aber die Parameter, Fehlercodes und was die Funktion genau macht (wenn sie ein Objekt verändert könnte das ja uU wichtig sein) sollte schon da stehen.

Nen gutes Beispiel finde ich den Linux QT, so stelle ich mir nen sauberen QT vor, allerdings gelingt es mir nicht immer

/Edit

Achja wenn ne Funktion mal so lang wird, dass man so viel kommentieren muss sollte man überlegen ob man diese Funktion nicht in weitere Funktionen zerlegen kann.

CarstenJ

Irgendwer meinte, Perl sei für viele Leute "write-only", und als ich das las, musste ich etwas schmunzeln..... :p

Leute, das der Code gut kommentiert sein sollte ist schon klar,
aber das war nicht die Frage, siehe Fragestellung:
"gut Dokumentiert = gut kommentiert".

Denn die eigentliche Fragestellung war, was ist mit dem programmiertechnischen Rest?

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.

Gregor schrieb:

- defensiver Programmierstil

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

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.