Einheitlich

pwned schrieb:

Kenner der Notation schrieb:

Ungemein wichtig!

Und Zeiger auf Fenster sollte man mit dem Präfix pWnd versehen

Insid0r

@ceplusplus: lass dich nicht verwirren. Ohne Präfixe kommst du in der Praxis kaum aus. Wie du ja siehst, spricht sich sogar der Weltmarktführer dafür aus: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp

Es gibt so ein paar "Profis", die was anderes sagen, aber die kannst du getrost ignorieren.

Kenner der Notation schrieb:

pwned schrieb:

Kenner der Notation schrieb:

Ungemein wichtig!

Und Zeiger auf Fenster sollte man mit dem Präfix pWnd versehen

Insid0r

@ceplusplus: lass dich nicht verwirren. Ohne Präfixe kommst du in der Praxis kaum aus. Wie du ja siehst, spricht sich sogar der Weltmarktführer dafür aus: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnvsgen/html/hunganotat.asp

Es gibt so ein paar "Profis", die was anderes sagen, aber die kannst du getrost ignorieren.

Nur weil MS die ungarische Notation verwendet, heißt es noch lange nicht, dass es die restliche Welt verwenden soll.

@ceplusplus: Lass dich nicht verarschen. Entwickel am besten deine eigene Notation,statt dir eine Notation aufzwingen zu lassen.

groovemaster

@ceplusplus
Wie mein Vorredner schon sagte, lass dich nicht so naiv belabern. Ich kann ja verstehen, dass einige Unregs sowas bei Newbies immer wieder gern versuchen. Deshalb, glaube nicht alles und versuche dir erstmal einen Überblick zu verschaffen, bevor du selbst entscheidest, was du machst.

ceplusplus schrieb:

Soll man Datenelemente einer Klasse mit "m_" vorbezeichnen?
Pointer mit "p" oder "ptr"?

Das hängt von deinem persönlichen Geschmack ab. Aber wie kingruedi schon sagte, Typinformationen im Namen zu verschlüsseln ist nicht wirklich sinnvoll. Wähle die Bezeichner erstmal plain und danach kannst du immer noch entscheiden, ob dir was fehlt und du die Namen anders schreibst.

ceplusplus schrieb:

Ist das wichtig?

Nein, ist es nicht. Es gibt aber durchaus sinnvolle Konventionen. Ungarische Notation ist keine (zumindest für C und C++), seine Member entsprechend zu markieren (ob mit Postfix _ oder Präfix m_) aber durchaus. Dazu kann ich dir noch den Tipp geben, lies dir mal den Artikel zur Ungarischen Notation bei Wiki durch, besonders den Abschnitt zu Vor- und Nachteilen. Wenn du eine vernünftige IDE verwendest, wirst du merken, dass es praktisch keine Vorteile gibt.

ceplusplus schrieb:

Worauf sollte/muss man beim Stil noch achten?

Nunja, wichtig ist auf jeden Fall, dass du deine Bezeichner einheitlich wählst. Nicht mal so und mal so. Und du solltest beim Wählen eines Namens primär darauf achten, dass er den Zweck klar und eindeutig wiedergibt.

finix

Lass lieber die Finger von Ungarischer Notation.

Zu diesem Thema gab's schon einige Threads , und die allgemeine, (nahezu) einhellige und gut begründete Meinung ist dass UN eher nutzlos bis schädlich ist...

Ich bin gegen ungarische Notation, aber Pointer sollte man trotzdem kennenzeichnen.

mantiz

Aufgrund Deiner Frage habe ich für mich auch nochmal überlegt. Bisher waren mir Member- und Pointervariablen eigentlich immer egal.
Jetzt mache ich es so:
Membervariablen beginnen immer mit "m_"
Pointer beginnen immer mit "p"
Membervariablen, die Pointer sind mit "m_p"

Methoden beginnen immer kleingeschrieben, da sie immer etwas tun, holen oder setzen, z.B.: setName(...), getName(), doSomething, etc.

Ansonsten werden Membervariablen immer groß geschrieben, also der erste Buchstabe und bei zusammengesetzten Namen immer der jeweils erste Buchstabe, natürlich nach dem Präfix, also z.B.: m_Name, m_BorderLeft, etc.

Bei Parametern habe ich bisher immer einen Unterstrich als Präfix verwendet, aber ich habe erst kürzlich erfahren, dass manche Compiler da evtl. Probleme machen könnten, da muss ich mir also nun was anders ausdenken.

Und für Referenzen bin ich mir noch nicht sicher, ob ich da auch noch nen Präfix verwenden soll, bin mir noch nicht sicher, ob das nützlich ist, obwohl ich erst kürzlich nen Fehler gesucht habe, wo ich einer Referenz eine andere Referenz zuweisen wollte, also eigentlich nur die Adresse, dabei habe ich die ursprüngliche Variable überschrieben. Würde also schon Sinn machen, denke ich.

Zur Ungarischen Notation muss ich noch sagen, dass es wohl irgendwann mal eine Daseins-Berechtigung hatte (weiß nicht mehr warum), ich ändere zwischendurch desöfteren mal den Typ einer Variablen, wenn ich dann jedes Mal die Präfixe ändern müsste, würde ich glaube ich Verrückt werden.

Für gewöhnlich weiß man ja bei einer Variablen zumindest so ungefähr den Typen, wichtiger ist hier, denke ich dem Namen mitzugeben, ob es sich um einen Member, Pointer, Referenz handelt, da das nicht immer ersichtlich ist. Leider kam diese Einsicht bei mir auch erst etwas spät.

CStoll

mantiz schrieb:

Zur Ungarischen Notation muss ich noch sagen, dass es wohl irgendwann mal eine Daseins-Berechtigung hatte (weiß nicht mehr warum), ich ändere zwischendurch desöfteren mal den Typ einer Variablen, wenn ich dann jedes Mal die Präfixe ändern müsste, würde ich glaube ich Verrückt werden.

Ja, die hatte eine Daseinsbereichtigung, als man damit noch die Bedeutung der Variablen gekennzeichnet hatte (z.B. zur Unterscheidung von Screen-Koordinaten und Client-Koordinaten (beides sind intern int-Werte)) - nur dann kam jemand auf die unheimlich clevere Idee, den Typ der Variablen durch UN zu beschreiben.

ich hasse die ungarische notation. bläht programme nur unnötig auf mit diesen ganzen bescheuerten zusätzlichen zeichen. lpszT lpK iPg lWndH ... der entsprechende entwickler soll selbsterklärende bezeichner für seine variablen wählen und sich nicht hinter der ach so genialen ungarischen notation verstecken! ob ne variable nen pointer oder char oder was auch immer ist, kann ich auch selbst nachgucken, falls es mich interessieren sollte.

lieber "verticesList_", als "m_rgdV"

Ich benutze UN unheimlich gerne.
Selbst nach einem Jahr Arbeit an den Quellen haben die Bezeichner immernoch ein einheitliches Schema. Besonders für Parameter in den Funktionprototypen finde ich das schick.
Ich benutze es aber nur für systemnahe Programmteile, für Klassenobjekte etc. tue ich es nicht.

Klappt wunderbar, da ich beide Teile weitgehenst zu trennen versuche.

UN ist gut. Schaden tut sowas mit Sicherheit nicht.

Bei modernen IDEs ist die UN sogar Kontraproduktiv. Gibt nichts schlimmeres als erstmal 5Buchstaben zu tippen für die UN bis man zum eigentlichen Variablennamen vorstößt, welchen man dann per Autovervollständigung einfügt.

ceplusplus

Hmm nun gut, dann werde ich mich mit der UN eher zurückhalten.
Jedoch halte bestimmte Bezeichnungen doch für sinnvoll:

m_datenelement //Member
p_zeigervariable //Zeiger

Mehr fällt mir momentan nicht ein, liegt wohl daran dass ich noch nicht viel weiter bin als bei Kapitel "Zeiger und Vektoren"

groovemaster

mobbel schrieb:

UN ist gut. Schaden tut sowas mit Sicherheit nicht.

Doch, genau das tut es. Nicht nur, dass das Benennen von Variablen erschwert, weil komplexer, wird. Auch die Lesbarkeit des Codes leidet darunter und es kommt schnell mal zu Inkonsistenzen. Variablen im Rahmen ihres Verwendungszweckes zu kennzeichnen ist ok, aber nicht den Typen im Namen anzugeben. Das ist bei einer OO Sprache vollkommen überflüssig.

Vor allem: Was nützt die Typenangabe im Variablennamen? Selbst wenn ich einem int ein float zuweise (ohne typecasting), dann werde ich spätestens zur compiletime merken.

fricki schrieb:

Vor allem: Was nützt die Typenangabe im Variablennamen? Selbst wenn ich einem int ein float zuweise (ohne typecasting), dann werde ich spätestens zur compiletime merken.

Es geht weniger um's Schreiben, sondern um's Lesen.

rüdiger

Ich sehe nicht wo die Lesbarkeit erhöht wird durch die UN. Eine Variable vertritt ein bestimmtes Konzept (Objekt -> Klasse). Der Punkt ist also das Konzept und nicht der Typ.

Ich denke die Benutzung von UN zeigt einfach ein Missverständnis (oder Missfallen) von Objektorientierung.

Da UN zusätzlich noch durch die Abkürzungen und unterschiedlichen Regelwerke alles andere als einheitlich ist, ist der Code so eher nur für Eingeweihte verständlich.

thordk

meine erste berührung mit ungarischer notation ist ewig her. hatte lange jahre mit pascal programmiert und musst dann irgendwann mal in die windows api (c++) gucken. die ganzen lHwd, lpsz, gurke23 vor jeder variable haben mich eigentlich nur verwirrt. ich will den verwendungszweck eines stücks code verstehen und nicht welche typen verwendet werden, was für das verständnis in 98% der fälle auch völlig irrelevant ist. falls mich der typ doch mal interessieren sollte, kann ich immer noch woanders nachgucken.

zumal grad in der api nur die header deklarationen stehen und da ist neben jeder variablen auch gleich der typ zu sehen ^^

UN ist nur was für Profientwickler, Hobbyfrickler sollten darauf verzichten.

finix

@SeppSchrott
Niemand wird dich daran hindern wollen selber UN einzusetzen, aber wenn du sie anderen anpreist solltest du echt mal irgendwann verraten was so furchtbar toll daran ist.
Oder warum du von den Gründen gegen UN nichts hälst, denn sie sind nicht, wie von dir behauptet, "nur Meinungen" sondern in der Tat "sachliche Argumente"; fang am besten beim jüngsten Thread zum Thema an, aus dem du dich, deine Proklamation "UN ist super" ausgenommen, so schön rausgehalten hast.
Und bitte wirkliche Gründe, Vorteile, etc; dein

SeppSchrott schrieb:

Ich benutze UN unheimlich gerne.
Selbst nach einem Jahr Arbeit an den Quellen haben die Bezeichner immernoch ein einheitliches Schema. Besonders für Parameter in den Funktionprototypen finde ich das schick.

hört sich zwar elegant an, sagt aber nichts weiter aus als "Ich benutze UN unheimlich gerne ... [weil ich das schick finde]."

Hallo funix,

hier noch einmal der Post, zu dem du Stellungnahme forderst.

Wie man an den Postings von Artchi und GPC sieht, gibt es dafür keine sachlichen Argumente, sondern nur Meinungen.

Ich werde das Thema aber dem Autor von dem Buch 'DirectX vs. OpenGl in 21 Jahren' vorschlagen. Damit ihr auf euren Kreuzzügen was in der Hand habt.

Diesmal mit kleinen Lesehilfen für dich.
Dieses militante 'Sag mir, wo du stehst' ist doch doof.

PS: Wenn ich sage, es seien keine sachlichen Argumente, sondern nur Meinungen, werden es nicht deshalb Fakten, weil ich anderen diese Meinungen lasse.