Name von Getter und Setter
-
@Nathan
Ansichtssache.
Für mich sind Funktionen Anweisungen/Befehle/Aufträge/Verben. Imperativ halt.
Und da macht "x" keinen Sinn. "get_x" dagegen schon.Ein Vorteil von "Funktionsname = Imerativ/Verb" ist z.B. dass man dadurch sehr gut klar machen kann ob eine Funktion bloss einen Wert zurückgibt (z.B. "get_rate") oder eine Aktion durchführt (z.B. "rate"). Bei der STL muss man es schlicht und einfach wissen.
str.empty().... hm.Was die Unterscheidung von "Eigenschaften" und "Untervariablen" angeht - das verstehe ich auch nicht ganz. Ist doch letztlich egal ob ein Abfragbarer Wert als eigene Membervariable vorliegt, errechnet wird, abgezählt wird, oder vielleicht sogar überhaupt konstant ist.
ps:
Bei boolschen Werten klingt GetX() oft doof - GetEmpty()? WTF? Daher verwende ich da dann sinnvollerweise oft IsX. Also IsEmpty, IsVisible etc.
-
hustbaer schrieb:
…
Volle Zustimmung.
hustbaer schrieb:
ps:
Bei boolschen Werten klingt GetX() oft doof - GetEmpty()? WTF? Daher verwende ich da dann sinnvollerweise oft IsX. Also IsEmpty, IsVisible etc.theStack.IsEmpty() fragt, ob der Stack leer ist. Ebenso myWindow.IsVisible(). Naja, doller Zufall, daß bool-Attribute oft was über das Objekt *this erzählen.
Mal angenommen, man dächte an ein Attribut isEmpty. Dann hieße der Getter dafür natürlich theStack.getIsEmpty().
Die Fensterbreite myWindow.getWith(), ok.
Obs einen Rahmen hat myWindow.hasFrame(), uups, "has" statt "is". Was ist denn da passiert?
myWindow.isFrame() wäre voll gelügt!
myWindow.getFrame() wäre direktes Proggern für die Tonne, weil jeder Normalstermliche jetzt eine struct FrameDescription oder so erwarte und sicher keinen bool.
-
Ja, stimmt, bei "IsX" gibt es ja wieder keinen Imperativ sondern nur den Namen einer Eigenschaft. Hmpf.
Sieht wohl nach einem Kompromiss aus.
Auf jeden Fall ist IsEmpty aber nicht - wie Empty - mit einem Imperativ verwechselbar.
-
hustbaer schrieb:
Ja, stimmt, bei "IsX" gibt es ja wieder keinen Imperativ sondern nur der Name einer Eigenschaft. Hmpf.
Gibt ja auch noch eine kleine Sonderrolle von Prädikatem, wie man in anderen Programmiersprachen so bool-Funktionen manchmal nennt. IstHübsch HatGeld KannKochen.
-
Ja. Sind dann halt zwei sprachliche Konstrukte die man erlaubt, Imperative und Fragen. Das ist denke ich noch OK
Ne Frage ist ja auch eine Art Imperativ, nämlich die Aufforderung zu antworten. Sogesehen ist es sogar recht konsistent.
-
Getter bekommen bei mir keinen Prefix. Setter bekommen ein set. Member mit Pre- und Suffixen finde ich schrecklich im Code zu lesen, auch wenn es nur ran geklebte Unterstriche sind. Meine IDE zeigt mir schon farblich an, was ein Member ist und was nicht. Und nein, ich möchte meinen Source nicht mit Notepad editieren oder ausdrucken. Ich nutze nicht umsonst eine IDE.
Ansonsten wird alles in CamelCase und Klassen in PascalCase benannt. Namensnennung mit Unterstrich finde ich auch schrecklich, das wirkt dann beim Drüberfliegen immer wie Whitespaces.
-
hustbaer schrieb:
Riecht für mich immer nach "trying to be cute".
heh ich weiß was du meinst.
aber ich bin lieber cute als set_width() oder setWidth() zu schreiben. Ich orientiere mich an einem Stil dem ich zustimme nicht nach der Gemeinschaft. Verstehe nicht wer das anders macht und wieso - du magst einen Stil nicht, benutzt ihn aber weil andere ihn benutzen? Außer wenn man in einem Projekt arbeitet schreibt man wie man selbst will nicht wie andere wollen.
-
Da gibt es einen schönen Spruch: "Ich bin nicht auf der Welt, um so zu sein wie andere mich gern hätten." Programmieren an alten Projekten oder im Team ist eh die Hölle. Man darf kaum neue Technologien einsetzen und muss sich auch noch an einen anderen Codingstyle halten.
-
@randa
Was man als schön, richtig oder stimmig empfindet wird massgeblich davon beeinflusst was man gewöhnt ist. Und was man gewöhnt ist hängt massgeblich davon ab was man sich angewöhnt. z.B. indem man es selbst verwendet.
Und so gesehen macht es für mich überhaupt keinen Sinn sich dinge anzugewöhnen die unüblich sind.
Zumindest nicht wenn zumindest eine der üblichen Alternativen Sinn macht.Also nein, ich verwende nicht einen Stil den ich nicht mag. Ich mag den Stil den ich verwende. (Nicht zu verwechseln mit: ich verwende den Stil den ich mag. Ich musste mir bestimmte Dinge auch erst angewöhnen.)
randa schrieb:
Außer wenn man in einem Projekt arbeitet schreibt man wie man selbst will nicht wie andere wollen.
Ich arbeite fast ausschliesslich an "Projekten". Ich mach' das schliesslich seit > 15 Jahren hauptberuflich.
Und ... was würde es da für einen Sinn machen privat etwas anderes zu verwenden?
-
Quote4All schrieb:
Da gibt es einen schönen Spruch: "Ich bin nicht auf der Welt, um so zu sein wie andere mich gern hätten."
Total hinderliche und sinnfreie Einstellung wenns ums Programmieren bzw. allgemein um Softwareentwicklung geht.
In der Softwareentwicklung hängt verdammt viel davon ab dass sich Leute an Konventionen halten. Und da kann dann nicht jeder seinen Dickschädel durchsetzen.Quote4All schrieb:
Programmieren an alten Projekten oder im Team ist eh die Hölle. Man darf kaum neue Technologien einsetzen und muss sich auch noch an einen anderen Codingstyle halten.
Wann programmiert man denn schon mal weder im Team noch an alten Projekten?
-
hustbaer schrieb:
Wann programmiert man denn schon mal weder im Team noch an alten Projekten?
Von den 10 Jahren, die ich beruflich programmiere(nicht C++), habe ich nur zwei Jahre im Team arbeiten müssen, sonst musste ich mich nur an Schnittstellen halten, aber mein Projekte konnte ich von der Pike auf komplett allein entwickeln. Bei mir ist also Team-Arbeit eher eine Ausnahme.
-
hustbaer schrieb:
randa schrieb:
Außer wenn man in einem Projekt arbeitet schreibt man wie man selbst will nicht wie andere wollen.
Ich arbeite fast ausschliesslich an "Projekten". Ich mach' das schliesslich seit > 15 Jahren hauptberuflich.
Und ... was würde es da für einen Sinn machen privat etwas anderes zu verwenden?jo gut...auch dann kann man seine Meinung reinbringen, statt auschließlich zu machen was andere Vorschlagen. Ich würde das bewerben was ich mache, nämlich std stil.
