Programmierstil
-
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.
-
hustbaer schrieb:
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?
Tut mir wahnsinnig leid, dass ich das Niveau über Codeformatierung heben wollte.
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.
War sowas von klar.
Benutzt eigentlich auch manchmal ein anderer deinen Account?
-
Nachdem ich ja vor kurzem auch ein paar Diskussionen da angestoßen habe, habe ich inzwischen folgende Meinung dazu:
- Codestylische Kleinigkeiten bzgl. Einrückungen oder wie Attribute geprä/post/garnicht-fixed werden sind immer noch Kleinigkeiten.
- Wer Programmierer danach bewertet wie sie diese Dinge handhaben, setzt falsche Prioritäten.Stil als größerer Begriff ist natürlich wichtig, aber schwieriger zu diskutieren, weil es da sehr fallbezogen ist.
-
also ich merke vor allem, wenn ich zwischen java und C++ switchen muss, dass der stil dann ein komplett anderer ist. die sache mit dem schreibstil hilft da sehr, weil ich in C++ mit underscores arbeite, in java in CamelCase (beide: klassen mit Großbuchstaben anfangen, variablen mit kleinbuchstaben, konstanten/enums GROSS) - this verwende ich in java eigentlich immer in konstruktoren, weil ich, immer wenn ein argument übergeben wird, das meistens gleich benenne, wie einen member. in C++ ist mir das ziemlich egal, weil
struct X { int y; X(int y) : y(y) { } };super funktioniert und andere sachen, die der konstruktor überprüfen muss, meistens in andere funktionen ausgelagert sind.
außerdem habe ich ganz gerne lange namen - besser ganze wörter als abkürzungen.
dann ist es auch stilsache, ob man einer klasse ein rieseninterface spendiert (was ich an vielen java-klassen nicht mag, dort aber üblicher ist als in C++, von string mal abgesehen) - außerdem verwende ich in java eher statische fabrikmethoden statt new; in C++ kommt mir schon immer wieder ein new unter, auch wenn mit make_shared & konsorten das in zukunft wohl weniger der fall sein wird.
in java verwende ich außerdem mehr objekte, die sich nicht mehr verändern lassen (also keine setter haben) und generell viel mehr klassen; dass bedingt dann auch etwa, dass getter keine referenzen auf containerklassen zurückgeben dürfen, sondern diese zuerst in einen "unmodifiable*"-wrapper packen.
das sind sachen, die in java nicht vorgeschrieben sind, aber zum "stil" gehören, der in C++ - auch wenn es genauso möglich wäre - niemals angewendet werden würden. auch die frage nach tiefen oder flachen klassenhierarchien etwa;
ich glaube, dass das alles zum stil gehört und als ich den threadtitel gelesen habe, dachte ich auch eher an das, was bashar geschrieben hat und war enttäuscht über die xste CamelCase diskussion.
