Programmierstil

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.

hustbaer

@Haarspalter

Exceptions dienen der Fallunterscheidung für Lösungswege die zum Zeitpunkt wo man den Code schreibt noch nicht bekannt sind.

Nö, das kann man so nicht sagen. Also kann man natürlich sagen, ich bin aber gänzlich anderer Meinung.

Exceptions dienen zur Ausnahmebehandlung. Und das sage ich jetzt nicht weil es die 1:1 Übersetzung von "exception handling" ist, sondern weil es ausnahmsweise auch mal sehr gut passt. Eine bessere kurze Umschreibung fällt mir nicht ein.

Ausnahmebehandlung heisst aber nicht, dass man zu dem Zeitpunkt wo man den Code schreibt noch nicht weiss wie man die Ausnahme behandeln möchte.

Ein besseres Kriterium wäre mMn.: wo (=wie weit weg vom Aufruf) will man den Fehlerfall üblicherweise behandeln, und gibt es Anwendungsfälle wo der Fehlerfall als "normal" anzusehen ist?

Heisst z.B. wenn ich nen Server schreibe, und da ne Database-Connection aufmachen will. In dem Fall weiss ich zwar wie ich den Fehlerfall behandeln will, aber es ist a) nicht der Normalfall dass das nicht klappt und b) will ich es nicht nahe der Stelle behandeln wo es passiert. Sondern irgendwo weit weg in einem "ich kann den Request aus irgend einem Grund nicht bearbeiten" Handler. Also schmeisse ich eine Exception. In meinem eigenen Code, und fange sie in meinem eigenen Code. Hier mit Returncodes zu arbeiten und über viele Callstack-Ebenen mit "if...return" zurückzusteigen, nur weil man weiss wie man den Fehlerfall behandeln wird, ist mMn. kompletter Unfug.

Anderes Beispiel: sagen wir ich schreibe ein Framework das File-IO abstrahiert. Hier weiss ich nicht wie der User darauf reagieren möchte, wenn man ein File nicht aufmachen kann. In dem Fall immer eine Exception zu werfen wäre allerdings der falsche Weg, denn es gibt verschiedenste Anwendungsfälle wo verschiedenste Sachen Sinn machen.

Es gibt Fälle wo der User z.B. gar nicht weiss ob ein File mit dem Namen überhaupt existiert, und den Fehler lokal behandeln möchte. Eine "CanOpenFile" Funktion anzubieten damit man die Exception vermeiden kann ist auch kein guter Weg, denn ob man ein File aufmachen kann oder nicht kann sich vom einen Moment zum nächsten ändern. Mal abgesehen davon dass es einen weiteren unnötigen Kernel-Call bedeuten würde. Also muss eine "TryOpenFile" Funktion her, die mit Returnwert arbeitet.

Dann gibt es aber Fälle wo der User wie im Fall der Database-Connection das File einfach haben "muss", nicht sinnvoll weitermachen kann und den Fehlerfall auch nicht lokal behandeln will. Also bietet man zusätzlich eine "OpenFile" Funktion an die im Fehlerfall eine Exception wirft.

Ein Framework das nur eine der beiden Möglichkeiten anbietet ist mMn. Murks.

Noch ein Beispiel: Werte aus einer Konfigurationsdatei lesen. Hier gibt es sogar drei Möglichkeiten: TryRead, Read mit Defaultwert und Read mit Exception. Alle drei können je nach Situation Sinn machen, und ich würde alle drei anbieten.

krümelkacker

Haarspalter schrieb:

[...bla...]
In dem Fall kann es auch reichen eine 0 zurück zu geben

FAIL

Haarspalter schrieb:

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

Wer sagt denn, dass man jeden Funktionsaufruf, der mit einer Ausnahme enden könnte, in ein try/catch klammern soll? Der Witz an der Ausnahmebehandlung ist doch, dass man Ausnahmen erst dort zu fangen braucht, wo man auch weiß, wie die Situation zu meistern ist. Ob da jetzt Framework Grenzen dazwischen liegen oder nicht, spielt doch keine Rolle.

Das ist guter Stil, alles andere ist Kinderkacke:

#define			      q [v+a]
#define			     c b[1]
#define			    O 1 q
#define			   o 0 q
#define			  r(v,a\
)v<0&&(			 v*=-1,		a*=-1);
#define			p(v,m,	    s,w)*c==*#v?2 q\
<m?(c++		       ,d=1,3	   q=0,5      q=m,main\
(a+3,b)		      ,o=o*s	 q,O=O*		 w q):0:
static		     d,v[99	];main		  (int a,
char**b		    ){d=7;     if(*c?!		  (p(+,3
,4 q+O*		   3,4)p(			   -,(o?3
:(O=1,6		  )),4 q			  -O*3,4)
p(*,4,3		 ,4)p(/				  ,5,4,3)
p((),d,		0+3,0+				 04)*c==
')'?2 q	       <02?(c				++,0):0
:(o=012	      *o+*c-			      '0',c++
,O=1)):	     2 q?3-			   2:printf(
"%d/%d"	    "\n",o		       ,O))return
1;d=a,r    (o,d)r		     (O,d)3 q
=o<O?(4	  q=o,O)		   :(4 q=O,
	 o);r(d,		 o)a+=3;O?
				 1:(O=1,2
				q=1);while
				(2 q=o%1 q)a++;v[d]/=O;d[
				v+1]/=O;return main(d,b);}

Von Steinar Hamre / ioccc.org