Programmierstil
-
== 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.
-
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?
-
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.)
-
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.
-
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.
-
[quote="Bashar"]
Wieso schreibst du das? Es ist mir klar, was gleichwertig heißt, ich hatte nach dem Zusammenhang zu qualitativ gut gefragt
'gleichwertige Optionen' = zwei oder mehr Wege zum Ziel
qualitativ gut hieß nichts anderes als den Anforderungen entsprechend. Anforderungen ist das bessere wort hier.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.
Das stimmt. Der Stil setzt sich aber zusammen aus dem Satz von Methoden und Paradigmen die dann im code stehen, egal ob der Programmierer das bewusst und systematisch wählt, oder nicht.
Der Arbeitsstil des Programmierers ist doch hier uninteressant. Nur was im code sichtbar ist gehört zum Programmierstil.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.
Die Formatierung rausnehmen ist aber nicht sinnvoll. Wie der Code Formatiert wird ist nicht nur Teil der Programmierpraxis, sondern variiert manchmal sehr von Programmierer zu Programmierer oder Firma zu Firma, also ist das Wort Stil hier passend.
Meine Defintition von Methode für diese Definition geht von Algorithmen und Datenstrukturen auf niedriger Ebene bis hin zu Design Patterns im OOP Sinne, also das was man tut um das konkrete Problem zu lösen wenn Sprache und ihr Featureset schon gewählt wurden. Benutze ich ein switch oder setze ich einen Funktionspointer, um zwischen verschiedenen Funktionen zu wählen, wie füge ich ein Element in einen Baum ein, wie organisiere ich Signale zwischen GUI-Klassen.
Und welche Methode der Programmierer benutzt gehört zum Stil wenn die Methoden gleichwertig sind.
-
Kontrasubjekt schrieb:
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.
Die Formatierung rausnehmen ist aber nicht sinnvoll. Wie der Code Formatiert wird ist nicht nur Teil der Programmierpraxis, sondern variiert manchmal sehr von Programmierer zu Programmierer oder Firma zu Firma, also ist das Wort Stil hier passend.
Ne, für Formatierung ist das Wort Formatierung passend. Formatierung kann man mit Tools ändern, den Stil kannst du nicht mit Tools änderen (unter der Annahme, dass du kein Tool hast, das Code lesen, verstehen und selber programmieren kann).
-
Ich finde es immer wieder erstaunlich wie man über Formatierung/Einrückung etc. diskutieren kann.
-
hustbaer schrieb:
Also erstmal muss das this-> da weg *schüttel*
Moment halt.
Was ist daran denn so schlimm?
Ich mache es meistens um die Unterstützung der IDE zu bekommen ^^, dann muss ich nicht so viel tippen, beziehungsweise die korrekten Namen wieder nachgucken (in den Header wechseln).
-
Nachteilig ist eigentlich nur, wenn man keinen Stil hat, also wildes, planloses Einrücken betreibt, Funktionen/Klassen/Variablen nach gemischten Stilen benennt. Dann hat es nämlich für alle eine einschränkende Wirkung beim Lesen.
Verwendet man einen einheitlichen Stil, so hat zumindest eine Gruppe keine Schwierigkeiten (die, die es auch so machen) und die anderen können sich daran gewöhnen - was übrigens erfahrungsgemäß durchaus geht.
-
schnellwas schrieb:
Ne, für Formatierung ist das Wort Formatierung passend. Formatierung kann man mit Tools ändern, den Stil kannst du nicht mit Tools änderen
Meinen gesamten code kann ich mit tools ändern (dem Editor), aber wie ist das relevant?
Du siehst doch in der Praxis zahlreiche verschiedene Stile die sich dadurch auszeichnen wie Klammern, namensgebung, case, Einrückung etc gehandhabt werden. Wenn also die Formatierung von code teil des Programmierens ist (und nicht ganz unwesentlich), dann gehört Formatierungsstil zum Programmierstil.
In der Praxis wird die Definition schon angewandt: du kannst dich darauf verlassen, dass bei einer Diskussion um Programmierstil Format erwähnung findet, ist hier im Forum so, ist bei mir in der Firma so gewesen, ich lese das in diesem Sinne in Artikeln online (Beispiel: der google coding styleguide, der wikipedia artikel), und andere haben bestimmt ähnliche Erfahrungen.
-
Kontrasubjekt schrieb:
schnellwas schrieb:
Ne, für Formatierung ist das Wort Formatierung passend. Formatierung kann man mit Tools ändern, den Stil kannst du nicht mit Tools änderen
Meinen gesamten code kann ich mit tools ändern (dem Editor), aber wie ist das relevant?
Entweder verstehst du überhaupt nicht, was Bashar und ich meinen oder du willst nicht. Ist mir aber auch egal.
-
Tim06TR schrieb:
hustbaer schrieb:
Also erstmal muss das this-> da weg *schüttel*
Moment halt.
Was ist daran denn so schlimm?
Ich mache es meistens um die Unterstützung der IDE zu bekommen ^^, dann muss ich nicht so viel tippen, beziehungsweise die korrekten Namen wieder nachgucken (in den Header wechseln).OK, dann lösch das this-> nachher einfach wieder weg.
Oder besorg dir ein Tool das dir die Unterstützung auch ohne this-> gibt - wie z.B. VisualAssist X.@schnellwas
Ach klar verstehen wir was ihr meint, bloss dass ihr eine sehr eigenwillige um nicht zu sagen sture Auffassung von Begriff "Programmierstil" habt, die nicht allgemein geteilt wird.Hier mal was zum nachlesen:
http://en.wikipedia.org/wiki/Style_guideDie Übersetzung "Stil" (für "style") mag im deutschen nicht optimal sein, "Form" würde es z.B. vermutlich besser treffen. Was gemeint ist sollte aber klar sein.
Und gemeint ist eben wie man seine Bezeichner nennt, wie man einrückt, wo man umbricht, Leerzeichen macht etc.
-
hustbaer schrieb:
Ach klar verstehen wir was ihr meint
Toll, jetzt ist es schon "wir" und "ihr". Macht doch eure dämliche bike shed discussion, mir doch egal.
-
Offensichtlich nicht, denn sonst hättest du dich ja nicht genötigt gefühlt zu versuchen einen Thread mit einer ganz klaren Fragestellung in eine andere Richtung zu zerren.
-
hustbaer schrieb:
@schnellwas
Ach klar verstehen wir was ihr meint, bloss dass ihr eine sehr eigenwillige um nicht zu sagen sture Auffassung von Begriff "Programmierstil" habt, die nicht allgemein geteilt wird.Du möglicherweise ein bisschen, aber wer meint, dass es bei diesem Zitat
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.
(haupsächlich) um Formatierung geht, hat nicht viel Ahnung vom Programmieren. Glaubst du ernsthaft du bist ein guter Programmierer, weil du schön formatierten Code schreibst? Dann wird jeder mit sowas http://www.prettyprinter.de/ zu einem guten Programmierer.
-
die antwort lautet: http://www.amazon.de/Clean-Code-Handbook-Software-Craftsmanship/dp/0132350882
-
@schnellwas
Natürlich ist es wichtiger wie der Code aufgebaut ist, als die genauen Konventionen nach denen Variablen benannt werden etc.
Ein Hinweis darauf ist auch OK.Das, und um was es in dem Zitat geht ist aber vollkommen unwesentlich, wenn der OP offensichtlich etwas anderes meint. Was er auch in seinem ersten Beitrag sowie damit
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.
ziemlich gut klargestellt hat.
Jetzt kann man auf die eigentliche Frage des OP eingehen, was ich getan habe. Oder man kann sich darüber auslassen dass seine Frage sinnlos ist, und sich selbst gut vorkommen, indem man hier rumspamt dass das doch alles unwesentlich ist.
-
hustbaer schrieb:
@schnellwas
Natürlich ist es wichtiger wie der Code aufgebaut ist, als die genauen Konventionen nach denen Variablen benannt werden etc.
Ein Hinweis darauf ist auch OK.Das, und um was es in dem Zitat geht ist aber vollkommen unwesentlich, wenn der OP offensichtlich etwas anderes meint. Was er auch in seinem ersten Beitrag sowie damit
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.
ziemlich gut klargestellt hat.
Jetzt kann man auf die eigentliche Frage des OP eingehen, was ich getan habe. Oder man kann sich darüber auslassen dass seine Frage sinnlos ist, und sich selbst gut vorkommen, indem man hier rumspamt dass das doch alles unwesentlich ist.
Oh Entschuldigung, dass ich die vierhundertzweiundachzigste und doch so wichtige Diskussion zum Thema Formatierung gestört habe.
Yada schrieb:
Ist die Forensuche kaputt?
Der aktuellste sich mit diesem Thema befassende Thread handelt die letzten paar Seiten nur noch um einen Penis. Soviel dazu.
Dann viel Spass, ihr kommt sicher wieder da hin.
-
schnellwas schrieb:
Oh Entschuldigung, dass ich die vierhundertzweiundachzigste und doch so wichtige Diskussion zum Thema Formatierung gestört habe.
Die Frage ist: warum hast du es nicht einfach lassen können?
schnellwas schrieb:
Yada schrieb:
Ist die Forensuche kaputt?
Der aktuellste sich mit diesem Thema befassende Thread handelt die letzten paar Seiten nur noch um einen Penis. Soviel dazu.
Dann viel Spass, ihr kommt sicher wieder da hin.
Mit deiner Hilfe sicher.