Konventionen

[Mr. B]

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

[otze]

die ungarische notation? ist absolut evraltet und wird fast kollektiv als schlechter stil betrachtet.

hier ein paar namenskoventionen:
klassentypen beginnen immer mit einem großbuchstaben also zb MyClass
der "_" in namen ist generell verpönt großbuchstaben trennen viel besser: my_func->myFunc; eine_variable->eineVariable

instanzen einer klasse haben immer einen sinnvollen namen der mit einem kleingeschriebenen buchstaben beginnt.

jegliche präfixe sind veraltet.
klassenpräfixe werden durch namespaces ersetzt

to be continued...

[Gast]

Würde mich gerne dem anpassen, weiß aber nicht, wie ich das lernen soll...

Gar nicht!!

[Mr. B]

aha, und du schreibst irgendwie? na dann

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