Programmierstil

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.)

Bashar

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.

Wieso schreibst du das? Es ist mir klar, was gleichwertig heißt, ich hatte nach dem Zusammenhang zu qualitativ gut gefragt (lies den Thread nach, warum). Irgendwie ist mir das aber auch zu blöd, darüber zu diskutieren, du musst darauf nicht antworten.

Programmierstil ist also eine Vorgehensweise weil Programmierstil eine Art und Weise ist, wie man code schreibt.

Wieso "also"? Naja egal. Also ich würde nicht sagen, dass alles, was ich in einer "Art und Weise" tue, eine Methodik hat; eine Methodik beinhaltet immer systematisches Vorgehen.

Man muss da übrigens noch weiter differenzieren: Man sieht einem Programm am Ende die Methodik nicht mehr unbedingt an, deshalb ist Programmierstil (= der in einem Programm sichtbare Stil) von dem Arbeitsstil des jeweiligen Programmierers (der hängt eher mit der Methodik zusammen) zu unterscheiden.

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.

Naja, die Formatierung hatte ich ja explizit ausgeschlossen, damit ist das jedenfalls nicht meine Definition. Und vielleicht haben wir ja unterschiedliche Ansichten zur Bedeutung von "Methodik", s.o.

hustbaer

zwutz schrieb:

== true ist aber (meist) sinnlos, ja

Ja.
Vor allem wenn man == true (oder == TRUE) mit Funktionen der WinAPI macht, die BOOL als int definiert.
Juchui. Alles schon gesehen (und nicht bloss einmal)...

Und wenn man schon == true weglässt, ... dann sollte man IMO == false auch weglassen.

zwutz schrieb:

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

finde ich lesbarer als

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

Also erstmal muss das this-> da weg *schüttel*

Ist halt Gewohnheitssache, wie man gewöhnt ist Code zu lesen und so - mir geht's genau andersrum.
Zum schnell lesen finde ich die Variante mit ! wesentlich besser, da ich mich beim schnell Lesen üblicherweise am linken Rand orientiere - das "== false" ist da einfach viel zu weit weg.

// Wenn ich von foo ein keks haben kann mit Dings und ... so eins wie ich will halt .... gähn .... zzZZzzZZzz ... OOPS, doch nicht
if (foo()->can_have_cookie(cookie_type, cookie_flavor, cookie_size, cookie_color, super_special_something_code) == false)

Ne, nicht gut zu lesen.