Präfixe
-
Wie benennt Ihr eigentlich eure Elemente ?
Gibst da irgendwo eine Liste wo man sich dran orientieren kann ?
Danke im voraus....
-
eigentlich gar keine ausser m_ für Klassenmembers. Die Namen meiner Variablen sind halt so stark das man daran den Typ erkennen kann.
-
HeikoKortlang schrieb:
eigentlich gar keine ausser m_ für Klassenmembers. Die Namen meiner Variablen sind halt so stark das man daran den Typ erkennen kann.
Angeber
-
gar nicht.
Programmier am besten so dass es nicht nötig ist. Die einzigen die das machen sind die Microsoft-Programmierer, und das sollte dir zu denken geben :p
-
Chickenman schrieb:
Programmier am besten so dass es nicht nötig ist. Die einzigen die das machen sind die Microsoft-Programmierer, und das sollte dir zu denken geben :p
Nö, ich mach das auch wenn es Sinn macht. Aber m_lpszFrgrMh macht in meinen Augen genausowenig Sinn wie K1, ..., KN als Klassennamen. Ich kennzeichne wenn es Doppeldeutigkeit geben könnte Zahlwerte mit i oder n (je nach dem ob signed oder nicht), Stings mit str und bool-Flags mit b. Achso, und Pointer markiere ich mit p. Muss jeder selber wissen. Ist ein beliebter Streitpunkt.
-
Phillip schrieb:
HeikoKortlang schrieb:
eigentlich gar keine ausser m_ für Klassenmembers. Die Namen meiner Variablen sind halt so stark das man daran den Typ erkennen kann.
Angeber
Heee... ich mach mit: Ich brauche nichtmal dieses "m_", weil meine Klassen und Methoden so aufgeräumt und überschaubar sind, dass sofort klar ist, was eine Membervariable ist und was nicht.
-
eine einheitliche Regelung für die Benennung von Variablen macht auf jeden Fall Sinn, ganz einfach weil man direkt sieht welchen Datentyp die Varable hat, und man nicht erst zur Deklaration scollen muss.
Das ganze nennt man übrigens ungarische Notation eine Liste der Prefixe findest du unter http://msdn.microsoft.com/library/en-us/dnw98bk/html/variablenameshungariannotation.asp genau diese Prefixe werden auch in der MSDN Library verwendet
mfg
j_freeze
-
Du ungarische Notation ist völlig veraltet.
-
MaSTaH schrieb:
Du ungarische Notation ist völlig veraltet.
jup
-
m_ für Elementvariablen. Wenn ich z.B. eine Variable für die Größe habe, heißt die m_size, damit die Zugriffsfunktion STL-like "size" und nicht "get_size" heißen kann, ohne, dass ich mit this rumhantiere. Postfix-Unterstriche finde ich schwerer sichtbar.
Vielleicht solltest du lieber fragen, wie wir überhaupt unsere Variablen benennen. stl_style, cstyl, javaStyle, vrblnbennngsstlMicrosoft?
-
operator void schrieb:
STL-like "size" und nicht "get_size" heißen kann, ohne, dass ich mit this rumhantiere.
Ich mag Methodennamen nicht, die nicht mit einem Verb anfangen. Das entspricht einfach nicht meiner Denkstruktur. Methoden machen halt etwas, deshalb sollte man sie auch mit Verben benennen. Wenn man das nicht macht, dann ist der Name nicht treffend. ...ähnliches gilt für Klassennamen, die man mit einem Substantiv benennen sollte und für Variablen usw.!
-
Gregor schrieb:
Methoden machen halt etwas, deshalb sollte man sie auch mit Verben benennen.
Naja, aber nicht alle. size() ist eher ein Attribut und macht eigentlich gar nix.
-
DrGreenthumb schrieb:
Gregor schrieb:
Methoden machen halt etwas, deshalb sollte man sie auch mit Verben benennen.
Naja, aber nicht alle. size() ist eher ein Attribut und macht eigentlich gar nix.
Doch. Es gibt Auskunft über die Größe. Deshalb ist ein getSize oder etwas ähnliches IMHO passender.
-
DrGreenthumb schrieb:
Gregor schrieb:
Methoden machen halt etwas, deshalb sollte man sie auch mit Verben benennen.
Naja, aber nicht alle. size() ist eher ein Attribut und macht eigentlich gar nix.
wehrlose attribute kommen eh nicht in die schnittstelle.
und getSize() und setSize() sind die beiden griffe, mit denen man size anfassen kann. eben lesend oder schreibend.
andauernd sehe ich ein dämliches size() in schnittstellen rumgammeln, das readonly ist. dann bin ich immer total verwirrt, weil vec.size()*=2 nicht geht und werde traurig.
-
Gregor schrieb:
DrGreenthumb schrieb:
Gregor schrieb:
Methoden machen halt etwas, deshalb sollte man sie auch mit Verben benennen.
Naja, aber nicht alle. size() ist eher ein Attribut und macht eigentlich gar nix.
Doch. Es gibt Auskunft über die Größe.
Naja, dann ist getSize schonmal total daneben. Glaubt man dem Namen, so bekäme sie die Größe; sie macht aber das genaue Gegenteil, sie gibt die Größe her.
-
volkard schrieb:
wehrlose attribute kommen eh nicht in die schnittstelle.
"Wehrlos"? Verstehe nicht ganz, wieso ist es mit get weniger wehrlos?
und getSize() und setSize() sind die beiden griffe, mit denen man size anfassen kann. eben lesend oder schreibend.
andauernd sehe ich ein dämliches size() in schnittstellen rumgammeln, das readonly ist. dann bin ich immer total verwirrt, weil vec.size()*=2 nicht geht und werde traurig.Kann ich nicht nachvollziehen, die beiden Klammern am Ende zeigen mir deutlich, dass es readonly ist. Bin noch nie auf die Idee gekommen, einer Funktion etwas zuweisen zu wollen.
-
DrGreenthumb schrieb:
Kann ich nicht nachvollziehen, die beiden Klammern am Ende zeigen mir deutlich, dass es readonly ist. Bin noch nie auf die Idee gekommen, einer Funktion etwas zuweisen zu wollen.
Naja, in der STL gibts da schon einiges: back, front, at... Aber verwechselt hab ich bisher noch nichts
-
Also die ungarische Notation halte ich für veraltet. Was wenn sich wärend der Entwicklung der Datentyp ändert? dann muss ich das über all korrigieren, tue ich es nicht, verwiirt es mehr, als das es nützt. Ich benenne meine Variablen und Funktionen lieber gleich so, dass man es erkennt:
Variable IsRunning. Was hat sie Wohl für ein Datentyp?
Variable FileSize wird wohl ein Integer Typ sein. Da in der DelphiLanguage DWORD, Integer, Cardinal, Int64 alle gleich behabdelt werden, spilet genaueres Wissen keien Rolle.
Genauso mit Funktionen:
HasBackSlash wird wohl was machen und was für einen Datentyp zurück geben? Genauso DelBackSlash, wird was machen und was zurückgeben?Nur in Ausnahmefällen, wenn mir nichts besseres eingefallen ist und der Datentyp nicht ekenntlich ist, benutze ich die ungarische Notation.
Allerdings nützt das alles nichts, wenn man in der Firma einen StyleGuide einhalten muss.
Auch, so einzige Ausnahme sind Typen, die fangen bei mir mit "T" an und Felder einer Klasse (entspricht Membervariablen in C++) fangen mit einem "F" an. Genauso, wie es im Borland ObjectPascal Styleguide steht: http://www.luckie-online.de/artikel/opstyleguide.shtml
-
operator void schrieb:
DrGreenthumb schrieb:
Bin noch nie auf die Idee gekommen, einer Funktion etwas zuweisen zu wollen.
Naja, in der STL gibts da schon einiges: back, front, at...
Oh, stimmt. Aber die Container sind da, denke ich, die Ausnahme. Eigentlich heißt es ja man soll keine nicht-const-Referenzen auf interne Dinge zurückgeben.
-
Ich mag Methodennamen nicht, die nicht mit einem Verb anfangen. Das entspricht einfach nicht meiner Denkstruktur. Methoden machen halt etwas, deshalb sollte man sie auch mit Verben benennen. Wenn man das nicht macht, dann ist der Name nicht treffend. ...ähnliches gilt für Klassennamen, die man mit einem Substantiv benennen sollte und für Variablen usw.!
Aber es entspricht genau meiner. Beispielsweise ein Auto. Es hat Fähigkeiten (kann fahren, bremsen, ...) und Eigenschaften (Farbe, ...). Fähigkeiten sind definitiv etwas, das durch Verben repräsentiert werden sollte, da es darum get etwas zu tun. Eigenschaften sind allerdings nichts, was man tuen kann oder tuen lassen kann. Und ich habe mein auto auch noch nie nach seiner Farbe gefragt (und ich bezweifle, das es mir antworten würde). Deswegen denke ich, das Eigenschaften durch Substantive besser beschreiben werden.
wehrlose attribute kommen eh nicht in die schnittstelle.
und getSize() und setSize() sind die beiden griffe, mit denen man size anfassen kann. eben lesend oder schreibend.
andauernd sehe ich ein dämliches size() in schnittstellen rumgammeln, das readonly ist. dann bin ich immer total verwirrt, weil vec.size()*=2 nicht geht und werde traurig.Deswegen hab ich mir meine Setter und Getter gebastelt. Mit denen ist quasi genau das auf recht einfache und übersichtliche weise Möglich, also vec.size *= 2;. Ohne ist das eher Problematisch.
Und von der Rückgabe von Referenzen würde ich auch abraten, da sonst ganz schnell versehentlich mal Blödsinn entsteht. Und selbst die würden bei volkrads size-Problem ja nicht helfen.