Konventionen

extractProductDataFromResultSet

Wenn man solche Namen vermeidet, kann man IMHO ganz gut ohne Unterstriche leben. Und wenn man OO programmiert, lassen sich solche Namen IMHO auch ganz gut vermeiden.

Bashar

Der Name ist ja nicht aus Spaß so lang, sondern soll sprechend sein. So aussagekräftig, dass man einen Kommentar einsparen kann. Eventuell machst du's dir auch etwas leicht, wenn du unterstellst, der Code sei kein OO. Kennst du das Buch oder den Autor?

Im Übrigen ... warum sollte man solche Namen denn vermeiden? Weil sie schwer zu lesen sind? Punkt für die Unterstriche

Ne, weil der Name IMHO keinen Sinn macht.

extractProductDataFromResultSet

-> getResultSet().extractProductData();

Jester

Optimizer schrieb:

Ne, weil der Name IMHO keinen Sinn macht.

extractProductDataFromResultSet

-> getResultSet().extractProductData();

Set().Result().get().Data().Product().extract();

Kennst Du den Kontext von dem Teil?
Falls nein, wie kannst Du beurteilen, daß er keinen Sinn macht?

Dem Titel des Buches glaube ich entnehmen zu können, daß es was mit Refactoring zu tun hat... da entsteht sowas gerne mal. Und aus gutem Grund.

Bashar

ResultSet und ProductData haben nichts miteinander zu tun, ResultSet weiß nicht, wie es ProductData erzeugen soll.

Gut, ich kenn dieses Teil nicht. Ich bin mir trotzdem sicher, dass sich dafür ein schönerer (= kürzerer und sprechenderer) Name finden lässt.
Oder willst du mir jetzt erzählen, dass der Name toll ist, mit oder ohne Unterstriche?

Jester schrieb:

Optimizer schrieb:

Ne, weil der Name IMHO keinen Sinn macht.

extractProductDataFromResultSet

-> getResultSet().extractProductData();

Set().Result().get().Data().Product().extract();

Kennst Du den Kontext von dem Teil?
Falls nein, wie kannst Du beurteilen, daß er keinen Sinn macht?

Dem Titel des Buches glaube ich entnehmen zu können, daß es was mit Refactoring zu tun hat... da entsteht sowas gerne mal. Und aus gutem Grund.

Das sollte doch jetzt nur mal exemplarisch sein. Natürlich weiss ich nicht, ob mein Vorschlag in dem Kontext Sinn gemacht hätte. Ich bin jedoch der Meinung, dass man meistens lange Namen gut vermeidet, wenn man Klassen einfach und klein hält und jede Methode nur genau eine Aufgabe erfüllen lässt.

volkard

bei extractProductDataFromResultSet ließe sich höchstens das FromResultSet killen. also nur noch extractProductData. der erste parameter ist ja eh ein ResultSet. das ist wie dieser moderne trick, daß man nicht mehr sortArrayOfIntWithSize schreibt, sondern sort(int* array,int size).
aber manchmal schreibt man in der tat noch die alte version hin. hab aber gerade vergessen, warum.
tut auch wenig zur sache. eher wichtig isses, daß man selten sowas wie extractProductDataFromResultSet hat. aber sowas wie resultSet oft.
eventuell ist es möglich, daß ein stil, den man sich in lisp erarbeitet hat, nicht voll klasse zu c++ passt. und natürlich kann man großbuchstaben schlechter lesen, wenn man großbuchstaben nicht gewohnt ist und unterstriche schlechter, wenn man die nicht gewohnt ist. das führt oft dann dazu, daß die leute bei genau dem bleiben, was sie zuerst gelernt haben und fertig.

Bashar

volkard schrieb:

bei extractProductDataFromResultSet ließe sich höchstens das FromResultSet killen.

OK von mir aus, kille was du willst. Der Code ist nicht von mir und ich bin es leid, den Namensstil zu verteidigen. Fakt ist, dass die Namen mir, so wie sie sind, als Buchstabenbrei erscheinen

eventuell ist es möglich, daß ein stil, den man sich in lisp erarbeitet hat, nicht voll klasse zu c++ passt. und natürlich kann man großbuchstaben schlechter lesen, wenn man großbuchstaben nicht gewohnt ist und unterstriche schlechter, wenn man die nicht gewohnt ist. das führt oft dann dazu, daß die leute bei genau dem bleiben, was sie zuerst gelernt haben und fertig.

Netter Ausflug in die Amateurpsychologie, aber 1) hab ich keinen Stil in Lisp erarbeitet, den man auf C++ übertragen könnte, 2) hab ich eher Schwierigkeiten, einen nicht von C++ beeinflussten Lisp-Stil zu finden, 3) hab ich mein ganzes Leben camelCase geschrieben und bin erst vor ca. 1 bis 1 1/2 Jahren umgeschwenkt (nachdem ich den Stroustrup gelesen habe übrigens.)

@Bashar: Du hast als Vorteil für Unterstriche aufgeführt, dass man damit lange Namen besser lesen kann. Wenn wir aber der Meinung sind, dass man lange Namen generell vermeiden soll, entkräftet das deine Argumentation IMHO etwas.

btw.: Ich mag es mir nicht unbedingt herausnehmen, aber ich bin bei weitem nicht mit allem einverstanden, was Stroustrup so schreibt. Vor allem finde ich seine Ratschläge stellenweise auch ziemlich schlecht begründet. Ich habe mir das Buch nur einmal ausgeliehen (und auch nicht vor es zu kaufen), deshalb weiß ich jetzt nicht, wie er seine Unterstriche begründet.

Bashar

Du hast als Vorteil für Unterstriche aufgeführt, dass man damit lange Namen besser lesen kann. Wenn wir aber der Meinung sind, dass man lange Namen generell vermeiden soll, entkräftet das deine Argumentation IMHO etwas.

Welche Argumentation meinst du? Das was ich nach wie vor sagen will ist, dass die Lesbarkeit nicht "rapide sinkt", wenn man Namensbestandteile mit Unterstrichen abtrennt (schon gar nicht dass diese Meinung hier im Forum ein Konsens ist). Nichts anderes. Soll jeder das nehmen was ihn glücklich macht, ich will überhaupt nicht behaupten, dass das eine oder das andere besser ist.

deshalb weiß ich jetzt nicht, wie er seine Unterstriche begründet.

Gar nicht. Er beschreibt die Sprache und keinen Stil. IMHO einer der Pluspunkte vom Stroustrup ... kein Oberlehrerhaftes "du darfst das und das nicht tun und musst das und das so und so machen".

Wie hat er dich dann von den Unterstrichen überzeugen können?

Bashar

Ich hab mich gefragt, warum er das wohl tut, und festgestellt, dass gemischte Groß/Klein-Schreibung einfach nicht das Wahre ist.

Helium

Heißt das, dass du gar keine Großbuchstaben mehr verwendest?

Bashar

Nein

Konrad Rudolph

Nette Diskussion, gefällt mir eigentlich ... und jetzt erkläre mir bitte noch jemand den ach so großen Vorteil der camelCase vor PascalCase. "Machen alle so" ist natürlich keine gültige Begründung.

operator void

Wenn man PascalCase für alles verwendet, hat man keine Unterscheidung zwischen Typen und Rest. Das gilt natürlich für jede Konvention, aber camelCase kenne ich eigentlich nur in 'gemischten' Konventionen. PascalCase wird in .NET z.B. für fast alles verwendet.

Konrad Rudolph

operator void schrieb:

Wenn man PascalCase für alles verwendet, hat man keine Unterscheidung zwischen Typen und Rest.

Nun ja ... der Unterschied sollte eigentlich aus dem Kontext erschließbar sein, nicht aus der Groß-/Kleinschreibung des Namens, die nicht gerade einen sehr lesbaren Unterschied darstellt.

just my € 0,02

operator void

Und ich finde es eklig, mir Synonyme und Abkürzungen für triviale Namen auszudenken. Ich will "stringToInt(String string)" schreiben können. Und "Map map". Wenn es nur ein Objekt gibt, dessen größtes Merkmal sein Typ ist, kann er auch so heißen.

Ich will "stringToInt(String string)"

und genau dafür kann man Funktionen überladen:

to_string(int);
to_string(double);
to_string(MeinType);

Das ist nicht nur ein Still Tipp! Man merke:

template<class T>
class MyTemplate{
  T t;
public:
  void foo(){
    to_string(t);
  }
};

Mit deinen stringToInt, stringToDouble etc geht sowas nicht.

So kommen wir nun zum eigentlichen Thema zurück damit wir auch ja nicht auf einen grünen Zweig kommen

Bei Variablen und Funktionen schreib ich alles klein und trenne die Wörter mit einem Unterstrich.

Bei Typen kommt es darauf an wofür sie gebraucht werden.

Ist es ein Type der sich ähnlich wie buildin Typen verhält, das heist ein Type der ==, =, CopyCtor, und kein virtual Dtor hat (das heist nicht zur public Vererbung taugt), also sowas wie std::string oder std::vector, dann schreib ich ihn wie Variablen und Funktionen. Do as the ints do und die machen es halt so.

Andern fals der erste Buchstabe eines jeden Wortes gross und Wörter aneinander wobei wenn man aufpasst selten viele Wörter aneinander reihen muss. Also:

Window win;

jedoch

Window::size size;

Wer seine Variablen und Typen immer schön lokal hält und seine Klassen und Funktion immer schön klein hält braucht auch fast keine Unterstriche, da sich Wörter wie size sehr sehr oft recyclen lassen, und fals einmal nicht kann man immer noch win_size draus machen.

Ach