Programmierstil

Kontrasubjekt

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

5cript

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

Mr X

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.

Kontrasubjekt

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.

hustbaer

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_guide

Die Ü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.

Bashar

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.

hustbaer

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

hustbaer

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

hustbaer

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?

Eisflamme

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.

krümelkacker

Bashar schrieb:

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

Das sehe ich auch so. Stil ist etwas anderes und beschränkt sich nicht auf die Formatierung.

Beispiel:

int length, *p;
if (fill(&p,&length) && length) {
  int minidx = 0;
  int minval = p[0];
  for (int k=1; k<length; ++k) {
    if (p[k]<minval) {
      minval = p[k];
      minidx = k;
    }
  }
  delete[] p;
  return minidx;
}
return -1;

versus

vector<int> v = vsource();
auto it = std::min_element(v.begin(),v.end());
if (it==v.end()) throw my_empty_exception();
return it - v.begin();

Die Aspekte bei diesem Beispiel:
- Wie wird mit Ressourcen umgegangen (RAII vs nackte Zeiger)
- Wird das Rad neu erfunden oder bedient man sich der std::Algorithmen?
- Wie sieht die Fehlerbehandlung aus? Special return values oder Exceptions?

krümelkacker schrieb:

- Wie sieht die Fehlerbehandlung aus? Special return values oder Exceptions?

Exceptions im eigenen Code um sie selber zu fangen und zu behandeln?

Exceptions dienen der Fallunterscheidung für Lösungswege die zum Zeitpunkt wo man den Code schreibt noch nicht bekannt sind. Z.B. im Falle der Frameworkentwicklung sinnvoll, da man nicht weiß was der Progger, der mit dem Framework arbeitet, mit der Info anfängt das der Vector leer ist.

Klar ist das auch ein Style für jede Funktion eine Excep. zu entwerfen und eine try/Catch Passage einzubauen, aber kein guter.

In dem Fall kann es auch reichen eine 0 zurück zu geben, im besten Fall an erster Stelle in der Funktion.