Präfixe
-
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.
-
Helium schrieb:
und Eigenschaften (Farbe, ...).
Warum modellierst du das dann nicht auch einfach als öffentliches Attribut? Ein Attribut ist schließlich eine Eigenschaft. Eine Methode ist keine Eigenschaft, sondern kann am ehesten mit "Verfahren" gleichgesetzt werden. Seit wann ist eine Eigenschaft ein Verfahren?
-
Warum modellierst du das dann nicht auch einfach als öffentliches Attribut? Ein Attribut ist schließlich eine Eigenschaft.
Weil du dann die Implementation unkontrolliert offenlegst. Zum einen kann die Klasse die Einhaltung ihrer Invariante nicht kontrollieren, dann kannst du das Attribut nicht read-only machen, und drittens kannst du dich später nicht mehr umentscheiden und das Attribut berechnen statt zu speichern.
Meine ideale Sprache würde syntaktisch keinen Unterschied zwischen Membervariablenzugriff und Aufruf einer Gettermethode machen (Eiffel und Common Lisp sind da ziemlich nah dran, bei Bedarf poste ich Code). C++ tut das aber. IMHO sind Proporties ein Schritt in die richtige Richtung.
Eine Methode ist keine Eigenschaft, sondern kann am ehesten mit "Verfahren" gleichgesetzt werden. Seit wann ist eine Eigenschaft ein Verfahren?
Stimmt schon, aber das ist nur aus Design-Sicht gültig. Bei der Implementierung entscheiden die konkreten Eigenschaften der vorliegenden Sprache, da kommt man letztlich nicht drumherum.