Konventionen
-
otze schrieb:
soweit ich mich erinner, wurde hier in mehreren threads davon abgeraten "_" zu benutzen, da die lesbarkeit rapide sinkt
die_Lesbarkeit_sinkt_aber_gar_nicht
dieLesbarkeitSinktGanzGewaltigWennManInCamelCaseSchreibt
-
volkard schrieb:
-funktionen und methoden gross, großbuchstaben als trenner, also "CloseFile". microsoft, borland und std::.
std::? Ich denk die schreiben alles klein?
-
Jester schrieb:
std::? Ich denk die schreiben alles klein?
ups. wie kommt std:: in diese zeile?
-
copy&paste?^^
-
Bashar schrieb:
otze schrieb:
soweit ich mich erinner, wurde hier in mehreren threads davon abgeraten "_" zu benutzen, da die lesbarkeit rapide sinkt
die_Lesbarkeit_sinkt_aber_gar_nicht
dieLesbarkeitSinktGanzGewaltigWennManInCamelCaseSchreibtwenn_du_nur_trenner_zwischen_deutschen_worten_betrachtest,
dann_sind_unterstriche_wohl_klug.
aber_wie_ist_es_bei_inner_wort_trennungen,
um_nicht_solche_wort_ungeheurer_zu_bauen?
sollte_man_da_nicht_zu_anderen_trennungsMitteln_greifen,
um_wortUngeheuer_zu_vermeiden?
um_es_auf_c++_zu_übertragen:
dort_sind_rennungen_zwischen_wörtern_duch_leerzeichen_erlaubt,
und wenn ich mich recht erinnere, machst du sogar leerzeichen um
operatoen, dann belien also nur noch die trennungen innerhalb von
wortUngeheuern. wieso willste dort was malen, was wie leerzeichen, also
wie wortTrenner aussieht? ich finde dein argument nicht überzeugend.
machste aber variablennamen, die ganze sätze darstellenAuto das_auto_wo_mir_ganz_alleine_gehoert;
, dann machste vermutlich nen schrecklichen lesbarkeitsfehler an anderer stelle.
für wörter wieAuto meinAuto;
finde ich die großbuchstaben als trenner stärker, weil sie eben *nicht* so stark
trennen, wie leerzeichen.
-
http://geosoft.no/development/cppstyle.html
imho ist es auch nur wichtig, dass man einheitlich schreibt
und das auch unter kolegen, wenn man gemeinsam an einem projekt arbeitet
und alle zugriff haben (müssen)cu
-
volkard schrieb:
wenn_du_nur_trenner_zwischen_deutschen_worten_betrachtest,
dann_sind_unterstriche_wohl_klug.
aber_wie_ist_es_bei_inner_wort_trennungen,
um_nicht_solche_wort_ungeheurer_zu_bauen?meine Variablennamen sind idR englisch, d.h. zusammengesetzte Wörter gibt es kaum.
für wörter wie
Auto meinAuto;
finde ich die großbuchstaben als trenner stärker
das funktioniert bei kurzen Wörtern wie toLower, deleteItem etc. auch ganz gut Jetzt schlag ich mal "Agile Software Development" von Uncle Bob auf und sehe da Bezeicher wie deleteProductData, extractProductDataFromResultSet, executeQueryStatement usw. Das ist für mich einfach nur Buchstabenbrei. Um da überhaupt irgendeine für mich verwertbare Struktur reinzubekommen, reichen Großbuchstaben nicht mehr aus.
BTW finde ich nicht, dass _ und Leerzeichen sich zum Verwechseln ähneln. Vielleicht magst du mal einen Blick in "Modern Compiler Design" von Dick Grune werfen, die Beispielprogramme dort sind in einer fiktiven Sprache, die auch Leerzeichen in Bezeichnern zuläßt ... *das* ist verwirrend und sieht auch ganz anders aus als wenn Wörter mit_Unterstrichen_zusammen_hängen.
Auch seh ich mich nicht als der Ritter des Heiligen Unterstrichs, ich will nur aufzeigen, dass es eben nicht so eindeutig klar ist, dass bei Unterstrichtrennung die Lesbarkeit "rapide sinkt".
-
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.
-
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();
-
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.
-
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.
-
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.
-
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.
-
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?
-
Ich hab mich gefragt, warum er das wohl tut, und festgestellt, dass gemischte Groß/Klein-Schreibung einfach nicht das Wahre ist.