Programmierstil

Yada

Ich hatte neulich eine Diskussion mit einem Kollegen und bin gerade - irgendwie - über einen entsprechenden Wikipedia Artikel gestolpert. In Diskussion wie auch Artikel ging es um etwas doch sehr wichtiges für (fast?) alle Programmierpsrachen: der Stil der Programmierung.

Nicht unwesentlich zu der ursprünglichen Diskussion hat wohl ein Zitat von Fowler:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

(mir ist schon klar, dass der Stil noch so schön sein kann und man trotzdem Schrott programmieren kann - aber Stil ist halt auch wichtig)

Dabei ist nicht die Bedeutung von Einrückungen relevant, die ohnehin unumstritten sein sollte, sondern eher: geschwungene Klammern in eine eigene Zeile packen? Methoden über CamelCase/(lowerCamelCase) benennen? Und so weiter.

Ich persönlich bevorzuge folgenden Stil (Pseudo-Sprache):

/**
 * A
 * simple
 * comment-block
 */
class aVeryLongClassName {
	/* littleInteger is integer */
	int littleInteger;

	/* littleChar is char */
	char littleChar;
}

const THIS_IS_A_CONSTANT = 0; // sometimes a horse looks through my window!

/**
 * void function
 */
void doSomething(int x, int y) {
	if((x == 5) && (y == 3)) {
		return ;
	} else {
		for(int i = 0; i <= x * y; i++) {
			return i;
		}
	}
}

Kurz:
1TBS-Stil und CamelCase. Außer Konstanten kriegen halt immer nur Großbuchstaben mit _. Was ich nicht mache, und vielleicht auch gar nicht mal so gut ist, ist Zeilenlänge beachten - so kommen dann schonmal längere horizontale Scrollbalken in der IDE raus, aber irgendwie stört mich das nicht...

Ich selbst habe mich aber schon öfters gefragt, ob ich nicht etwas ändern sollte:
- Nur Methoden cc benennen und Variablen einfach zB little_integer.
- Nicht selten findet man, vorallem bei If-Bedingungen oder allgemein klammerbedingter Syntax das Phänomen, dass man die Leertaste etwas vergewaltigt:

if( bedingung == true && ( wasweissich == false || hastenichtgesehen == true ) )

Persönlich habe ich das mal eine Zeit lang gemacht, inzwischen wieder aufgehört. Ich frage mich aber immer wieder, ob der Stil eigentlich gar nicht so schlecht ist. Beruflich kann ich mir keine Resonanz über die Leserlichkeit erwarten, da ich der einzige Webentwickler in der Firma bin :p (und mich mit anderen Sprachen wie C++, Java, etc. nur als Hobby befasse - folglich ließt das normal auch kein Mensch, außer ich)... Und selbst ist es mir relativ egal, da ich, wie gesagt, beide Stile durchgemacht habe.
- mehr auf Zeilenlänge achten? :>

Zudem würde mich einfach mal die allgemeine Meinung dieses Forums dazu interessieren. Welchen Stil verwendet ihr?

Patrickssj6

Member Sachen mit "m_" Prefix.

Alles andere CamelCasing mit großen Anfangsbuchstaben außer Parameter (kleine Anfangsbuchstaben).

KingKarl

Patrickssj6 schrieb:

Alles andere CamelCasing mit großen Anfangsbuchstaben außer Parameter (kleine Anfangsbuchstaben).

camelCase hatte ich früher auch, aber...

abends_find_ich_es_einfach_unleserlich
abendsFindIchEsEinfachUnleserlich

Swordfish

Patrickssj6 schrieb:

[...]

*würg*

Bashar

IMHO sind das Kleinigkeiten, die mit Stil überhaupt nichts zu tun haben.

Patrickssj6

Swordfish schrieb:

Patrickssj6 schrieb:

[...]

*würg*

Lass mich raten: Noch dazu programmierst du auf nem MacBook mit Kubuntu damit du garantiert ganz alternativ bist.

Wie mein Vorgänger gesagt hat: Hier kann man kaum von einem Programmierstil sprechen sondern eher von Konventionen.

Swordfish

Patrickssj6 schrieb:

Swordfish schrieb:

Patrickssj6 schrieb:

[...]

*würg*

Lass mich raten: Noch dazu programmierst du auf nem MacBook mit Kubuntu damit du garantiert ganz alternativ bist.

Noch wozu? Du fühlst Dich offenbar einfach auf den Schlips getreten.

Patrickssj6 schrieb:

Wie mein Vorgänger gesagt hat: Hier kann man kaum von einem Programmierstil sprechen sondern eher von Konventionen.

So hab' ich den Ausdruck "Stil" in diesem Zusammenhang auch verstanden.

Ich muss den Thread nicht mal lesen um zu wissen, dass hier Leute frisch ein mittelprächtiges C++ Buch zu Ende gelesen haben und jetzt ihre neu gewonnene Weisheit im Forum kundtun.

Es gibt keinen guten und auch keinen schlechten Stil. Es gibt nur unterschiedliche Stile. Sofern man es halbwegs konsequent einhält, ist alles in bester Ordnung.

Wer einen Stil propaiert hat nichts verstanden.

Yada schrieb:

Welchen Stil verwendet ihr?

Es gab hier im Forum sicherlich schon dutzende sinnlose Diskussionen darüber.

Aber na gut:

Für Member nehme ich auch das m_-Prefix, nicht nur aus dem Grund, weil ich es sonderlich schön finde, sondern dies eher mit der Benutzung von Visual Assist zu erklären ist: 'm' gefolgt von der linken Shifttaste wird zu "m_" und ein Dialogfenster zeigt mir daraufhin alle Member der Klasse - nicht unbedingt nötig doch praktisch.

/**
 * A
 * simple
 * comment-block
 */
class aVeryLongClassName {
    /* littleInteger is integer */
    int littleInteger;

    /* littleChar is char */
    char littleChar;
}

Das wären mir schon bedeutend zu viele Kommentare.

void doSomething(int x, int y) {
    if((x == 5) && (y == 3)) {
        return ;
    } else {
        for(int i = 0; i <= x * y; i++) {
            return i;
        }
    }
}

Dem else würde ich schon eine eigene Zeile spendieren, den Klammern eigentlich auch, aber das ist wirklich Geschmackssache.

if( bedingung == true && ( wasweissich == false || hastenichtgesehen == true ) )
// würde ich als
if(bedingung && (!wasweissich || hastenichtgesehen))

schreiben.

hustbaer

Also was mir an dem gezeigten Beispiel am wenigsten in den Kram passt:

* {} bekommen eigene Zeilen
* Nach control-flow Keywords mache ich ein Space (if, for, switch, ...)
* Member heissen m_fooBar
* Klassen- und FunktionsNamen fangen gross an
* == true und == false geht gar nicht (vor allem == true!)

Weiters

* Bei einzeiligen "Blöcken" lasse ich die {} weg
* Einzeilige Kommentare kommen hinter das Member/Statement/... und zwar mit //
* Mehrzeilige Kommentare bitte ohne die komischen " *" und wenns geht auch mit //

namen_mit_unterstrich finde ich auch OK, aber dann bitte nicht mischen. Also entweder alles mit Kamel oder alles mit _.

Bashar schrieb:

IMHO sind das Kleinigkeiten, die mit Stil überhaupt nichts zu tun haben.

Yada schrieb:

Nicht unwesentlich zu der ursprünglichen Diskussion hat wohl ein Zitat von Fowler:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Bei dem Zitat ist sicher nicht die Formatierung von Code oder irgendwelche Perfix Sachen gemeint. Viele hier meinen, sie wären gute Programmierer, wenn sie komplizierten Code schreiben können, bei dem andere lang brauchen ihn zu verstehen, aber eigentlich ist es andersrum. Der der das gleiche Problem mit einfacheren und klaren Algorithmen/Design löst, ist der bessere Programmierer (gleiche/bessere Performance eingeschlossen).

Noch besser ist übrigens ein Programmierer, der nicht nur Code schreibt den jeder lesen kann, sondern auch noch Klassen designt, die jeder auf Anhieb richtig verwendet, ohne groß Erklärung und vorher den Inhalt der Klassen lesen zu müssen. (gutes API Design)

Yada schrieb:

...

*gähn*

Ist die Forensuche kaputt?

jhggfdsfgh schrieb:

Es gibt keinen guten und auch keinen schlechten Stil. Es gibt nur unterschiedliche Stile. Sofern man es halbwegs konsequent einhält, ist alles in bester Ordnung.

Doch es gibt schlechten Stil.
Führ Dir einfach mal Code Complet zu Gemüte.
Kleines Beispiel:

if(a==b||a1!=f1&&fl==(al-1) foo(a1,al,f1); mk_mull(fl,a1); al=4711;a1|=kzUp;

Dazu noch ein Paar gotos oder longjmps eingestreut.
Und nun stell dir mal ein Programm mit mehr als 256 Zeilen eines solchen Codestils vor, der konsequent durch gehalten wird.
Also GWBasic-Stil mit C.

Kontrasubjekt

Bashar schrieb:

IMHO sind das Kleinigkeiten, die mit Stil überhaupt nichts zu tun haben.

Ich hab Stil in diesem Forum häufig in diesem Kontext gesehen.
Wie definierst du stil? Die Art und weise, wie Probleme gelöst werden, wenn mehrere (quasi)gleichwertige Optionen verfügbar sind?

Bashar

Kontrasubjekt schrieb:

Bashar schrieb:

IMHO sind das Kleinigkeiten, die mit Stil überhaupt nichts zu tun haben.

Ich hab Stil in diesem Forum häufig in diesem Kontext gesehen.

Ja und?

Wie definierst du stil?

Stil kann man nicht einfach so definieren. Aber setz mal zwei Programmierer an dasselbe hinreichend umfangreiche Problem, dann bekommst du zwei vollkommen unterschiedliche Programme, selbst wenn du die Formatierungskonventionen ausblendest. Das ist Stil.

Die Art und weise, wie Probleme gelöst werden, wenn mehrere (quasi)gleichwertige Optionen verfügbar sind?

Warum unbedingt gleichwertig? Das meiste ist sowieso subjektiv.

zwutz

hustbaer schrieb:

== true und == false geht gar nicht (vor allem == true!)

dem will ich teilweise widersprechen. Mir ist es schon paarmal passiert, dass das kleine ! in etwas längeren Ausdrücken gern mal nicht die Präsenz einnimmt, die es sollte. Gerade wenn man mit der Rückgabe von Methoden direkt arbeitet. Deswegen hab ich schon paarmal wieder auf == false geändert, einfach um das ganze etwas deutlicher für die Querleser zu machen

if (this->foo()->is_done() == false) ...

finde ich lesbarer als

if (!this->foo()->is_done()) ...

== true ist aber (meist) sinnlos, ja

Kontrasubjekt

Bashar schrieb:

Stil kann man nicht einfach so definieren. Aber setz mal zwei Programmierer an dasselbe hinreichend umfangreiche Problem, dann bekommst du zwei vollkommen unterschiedliche Programme, selbst wenn du die Formatierungskonventionen ausblendest. Das ist Stil.

Also stimmst du meinem Definitionsvorschlag zu(Stil ist Methodik). Denn das geht aus deinem zweiten Satz hervor.
Stil ist eigentlich recht einfach zu definieren: Man könnte sagen coding convention(name, brackets, case etc), oder Methodik, oder beides. 'Beides' ist die Definition von stil die in der Praxis hier, aber auch anderswo angewandt wird.
Ein Biespiel von hier ist der thread zum doom3 source release, wo gesagt wurde dass der c-lastige c++ code in doom3 ein stil sei, eine Art und Weise, die Probleme anzugehen(in dem Fall war gemeint: mit abgespecktem OOP).

Warum unbedingt gleichwertig? Das meiste ist sowieso subjektiv.

Stil hat diese Konnotation eben. Man kann Probleme auf unterschiedliche weisen angehen, und wenn am ende zwei qualitativ gute Lösungen rauskommen, die unterschiedlich sind, dann kann man stil sagen und es für subjektiv erklären, wenn die eine aber in diesem oder jenem Aspekt schlechter ist, dann ist der eine Stil einfach nur schlechter programmieren.

edit: quote fail

Yada

== true und == false geht gar nicht (vor allem == true!)

Wie gesagt, Pseudo-Code. War spät gestern und mir gingen einfach die Wörter bzw. Variabelnamen aus - daher einfach irgendwas genommen was "gerade so da war".

Bei dem Zitat ist sicher nicht die Formatierung von Code oder irgendwelche Perfix Sachen gemeint.

Wie gesagt, war klar das das Zitat Formatierung nicht als Sinn hatte. Aber irgendwie kamen wir halt von diesem Zitat zu genannter Diskussion.

Ist die Forensuche kaputt?

Der aktuellste sich mit diesem Thema befassende Thread handelt die letzten paar Seiten nur noch um einen Penis. Soviel dazu.

Bashar

Kontrasubjekt schrieb:

Also stimmst du meinem Definitionsvorschlag zu(Stil ist Methodik). Denn das geht aus deinem zweiten Satz hervor.

Nö tue ich nicht. Methodik ist eine Vorgehensweise, Stil nicht. Stil ist vielleicht (teilweise) das Ergebnis einer Methodik. Eine Methodik auszuwählen gehört aber schon wieder zum Stil. Sicher hängt das zusammen, aber das ist nicht die Definition.

Warum unbedingt gleichwertig? Das meiste ist sowieso subjektiv.

Stil hat diese Konnotation eben. Man kann Probleme auf unterschiedliche weisen angehen, und wenn am ende zwei qualitativ gute Lösungen rauskommen, die unterschiedlich sind, dann kann man stil sagen und es für subjektiv erklären, wenn die eine aber in diesem oder jenem Aspekt schlechter ist, dann ist der eine Stil einfach nur schlechter programmieren.

Ich versteh den Zusammenhang zu "gleichwertig" nicht. Oder ist automatisch alles gleichwertig, was "qualitativ gut" ist?

Kontrasubjekt

Bashar schrieb:

Nö tue ich nicht. Methodik ist eine Vorgehensweise, Stil nicht. Stil ist vielleicht (teilweise) das Ergebnis einer Methodik. Eine Methodik auszuwählen gehört aber schon wieder zum Stil. Sicher hängt das zusammen, aber das ist nicht die Definition.

Ich versteh den Zusammenhang zu "gleichwertig" nicht. Oder ist automatisch alles gleichwertig, was "qualitativ gut" ist?

Analogie: Wenn zwei Leute auf unterschiedliche Art und Weise laufen, aber beide die 100m zur gleichen Zeit schaffen, dann ist es unterschiedlicher Stil und gleichwertig, obwohl de facto nicht gleich gelaufen wurde. Wenn der eine langsamer war, dann hat er auch einen unterschiedlichen Stil, aber er war auch objektiv langsamer.

Beim ersten Fall sagt man "ihr habt unterschiedlichen code, aber beide sind gemessen an den Anforderungen des projekts gleich gut." und impliziert damit, dass die Lösungen gleichwertig sind trotz des unterschiedlichen codes. Beim zweiten Fall nicht.
Programmierstil ist also eine Vorgehensweise weil Programmierstil eine Art und Weise ist, wie man code schreibt. Die Wahl der Methode kann zu dieser Art und Weise gehören, wie du auch sagtest. Auch deinen Satz lese ich so:

Aber setz mal zwei Programmierer an dasselbe hinreichend umfangreiche Problem, dann bekommst du zwei vollkommen unterschiedliche Programme, selbst wenn du die Formatierungskonventionen ausblendest. Das ist Stil.

Und damit sollten wir doch schon eine Definition haben:
Programmierstil ist die Formatierung des codes, die Wahl der Methodik zur Lösung von Problemen und die Wahl des Programmierparadigmas.
(Paradigma ist ein Level höher als die Methodik, zu der Algorithmen gehören können, daher gesondert.)