Konventionen

[Jester]

otze schrieb:

der "_" in namen ist generell verpönt großbuchstaben trennen viel besser:

Es gibt beide Styles.

[otze]

soweit ich mich erinner, wurde hier in mehreren threads davon abgeraten "_" zu benutzen, da die lesbarkeit rapide sinkt

[volkard]

Mr. B schrieb:

Hallo!
Kennt vielleicht jemand einen Link zu einer Seite, auf der alle Konventionen und Beschlüsse zur korrekten Schreibung der Variablen stehen?
Also z. B., dass man Zeiger mit Vorsatz 'p' schreibt, Makros nur mit Großbuchstaben usw. Würde mich gerne dem anpassen, weiß aber nicht, wie ich das lernen soll...
Mr. B

es gibt keine solche seite.
ich hab mal in ner firma gearbeitet, da haben wir alle namen von attributen rückwärts geschrieben, damit man sie besser von lokalen variablen unterscheiden kann. hat sich aber nicht durchgesetzt.
solche experimente geschehen aber anauernd und jeder, der sich berufen fühlt, so eine aufstellung der guten konventionen zu machen, empiehlt auch sachen, die sich später als mist herausstellen werden.
gängig sind wohl:

-klassennamen groß anfangen, also "Auto, Keller". das war wenigstens mal sogar zwischen win und linuxern einheitlich gewesen und damit de fakto standard. leider hat das c++-standardisierungskommitee beschlossen, daß man c++ auch mit fernschreiben ohne großbuchstaben benutzen können soll und gar nix mehr groß geschrieben. mit dem erfolg, daß in manchen kontexten kleinschrift herrscht und in manchen nicht.

-methoden und funktionen als verben (gegebenenfalls mit objekten), also "close, removeDirectory". auch hier hat dieser karnevalsverein was anderes gemacht mit "size() und end()". mit ähnlichem erfolg.

-variablennamen klein, goßbuchstaben als trenner, also "meinAuto, leistungInKilowatt". einheitlich (bis auf std::, wie immer).

-funktionen und methoden klein, großbuchstaben als trenner, also "closeFile". einheitlich außer microsoft, borland und std::.

-funktionen und methoden gross, großbuchstaben als trenner, also "CloseFile". microsoft, borland und std::.

-attribute mit kleinem m_ am anfang. microsoft, borland.

-klassen mit C am anfang. microsoft.

-makros GROSS. alle außer microsoft.

-konstanten gross. microsoft kennt keine konstanen, std:: kennt keine großbuchstaben.

du siehst, es herrscht überhaupt keine ordnung. ich kann nur empfehlen, sich weder an die standard-schreibung noch an die ms-schreibung zu halten.

[Gast]

Ich habe schon meine Konventionen, allerdings nicht die ungarische Notation.

Grundsätzlich ist es bei einer Variablen wichtiger zu wissen, was sie macht und welche Bedeutung sie im Programm hat. Nicht, von welchem Typ sie ist. Das solltest du im Hinterkopf behalten, dann ist das Schlimmste schon mal verhindert.

EDIT: Ich empfehle die Java-Konvention zur Namensgebung. Wobei die es bei den Collections auch schon wieder verplant haben und die Methode einfach size() nennen.

[Bashar]

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

[Jester]

volkard schrieb:

-funktionen und methoden gross, großbuchstaben als trenner, also "CloseFile". microsoft, borland und std::.

std::? Ich denk die schreiben alles klein?

[volkard]

Jester schrieb:

std::? Ich denk die schreiben alles klein?

ups. wie kommt std:: in diese zeile?

[otze]

copy&paste?^^

[volkard]

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
dieLesbarkeitSinktGanzGewaltigWennManInCamelCaseSchreibt

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?
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 darstellen

Auto das_auto_wo_mir_ganz_alleine_gehoert;

, dann machste vermutlich nen schrecklichen lesbarkeitsfehler an anderer stelle.
für wörter wie

Auto meinAuto;

finde ich die großbuchstaben als trenner stärker, weil sie eben *nicht* so stark
trennen, wie leerzeichen.

[ERROR]

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

[Bashar]

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

[Gast]

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

[Gast]

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.

[Gast]

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?

[Gast]

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