Name von Getter und Setter

[GetSetWilly]

Es geht doch hier nicht darum, wer wie viele Getter/Setter einbaut und ob das Sinn macht. Es geht hier um eine Frage zur Namenskonvention.

[hustbaer]

@GetSetWilly
Ich empfinde es schon als Fortschritt, dass sich hier keiner blöd von der Seite anmachen lassen musste, nur weil er es wagt sich Gedanken über solche "unwichtigen" Dinge wie Benamsung/Formatierung/... zu machen.

Hatten wir nämlich auch ne Zeit lang.

[cooky451]

hustbaer schrieb:

GetValue und SetValue.

Leicht off-topic, aber: Du scheinst Methoden/Funktionen in CamelCase zu schreiben. Machst du das mit Typen und Variablen auch so?

[GetSetWilly]

@hustbaer:
Es gibt ja mittlerweile sogar schöne Bücher darüber, wie "Weniger schlecht Programmieren" von OReilly.

@cooky451:
Gegen CamelCase spricht doch nichts, wird in Qt bis auf die Member nur so gemacht und ich finde das übersichtlich.

[cooky451]

GetSetWilly schrieb:

Gegen CamelCase spricht doch nichts

Ganz im Gegenteil, ich finde es eigentlich relativ hübsch, es sieht halt nur leider etwas doof aus zusammen mit stdlib-Code. das_gilt_aber_für_alles_was_nicht_so_aussieht.

[hustbaer]

Ist aber auch ein Vortail dass es anders aussieht.
Sieht man wenigstens gleich was eigener Code bzw. ThirdParty Code ist.

[hustbaer]

@GetSetWilly
Leider gibt es trotzdem immer wieder Leute die sich über Diskussionen zu diesen Themen lustig machen müssen. So nach dem Motto "das ist ja nicht wichtig, viel wichtiger ist XYZ".

Wobei ich vermute dass das oft einfach Leute sind die eben "viel schlecht" programmieren, und das nur noch nicht bemerkt haben. Bzw. zu faul sind "weniger schlecht" zu programmieren, und versuchen sich mit Polemik zu verteidigen.

GetSetWilly schrieb:

@hustbaer:
Es gibt ja mittlerweile sogar schöne Bücher darüber, wie "Weniger schlecht Programmieren" von OReilly.

Cool, danke für den Tip.
Kennst du das Buch? Ist das empfehlenswert? Die Amazon Reviews sind ja durchaus positiv.

[GetSetWilly]

Ja, ich habe das Buch von meiner Frau geschenkt bekommen und es geht auch auf so Sachen ein, wie man denn die Namen für seine Elemente so wählen könnte, wie "isOpen" oder "numItems". Oder wann man für seine Funktion einen Namen wie "combine" nimmt und wann "merge", wann "split" und wann "splice/slice" usw. Und das man englische Bezeichner und Kommentare nehmen sollte, falls es auch mal ein anderer lesen und verstehen soll. Aber auch Themen fürs Team oder Debugging und Testing sind dabei. Irgendwie ein bunter Mix aus allem, was so um das Programmieren drumherum abläuft und wichtig sein könnte. Es ist auch immer nur ein Leitfaden, wo dann jeder selbst entscheiden kann, was er übernimmt und was nicht. Ich würde es gut finden, wenn sich mehr Leute mit solchen allgemeinen Programmierer-Themen beschäftigen würden.

Schlechter wird der Code mit Sicherheit durch das Buch nicht.

[randa]

Wenn ich welche schreibe orientiere ich mich am Stil der standardbibliothek.

void value(int);
int value();

[SeppJ]

randa schrieb:

Wenn ich welche schreibe orientiere ich mich am Stil der standardbibliothek.

void value(int);
int value();

Du meinst so wie ios::rdstate() const und ios::setstate(iostate) ? Oder doch eher so wie ios::width() const und ios::width(streamsize) ? Also ganz konsistent und einheitlich?

[hustbaer]

Vor allem...
Bei der Standard-Library ist es "OK" wenn Dinge stellenweise etwas kryptisch sind, wenn sie dafür kürzer werden.
Die Standard-Library sollte schliesslich jeder kennen. Zumindest die "üblichen" Klassen.

Bei eigenem Code kann man das nicht voraussetzen. Daher ist das "Argument" ist gut, die STL machts schliesslich genau so nicht unbedingt sinnvoll.

[GetSetWilly]

Mir fällt auf, dass ich noch gar nicht die Frage hier beantwortet habe. Also ich nenne die Getter auch nur noch dem Rückgabewert und bei den Settern kommt ein set Prefix davor. Getter und Setter kommen aber nicht sooo häufig vor. Getter machen ja im Prinzip nur private Member publicread(was man auch als Schlüsselwort einfügen sollte). Getter und Setter ohne irgendwelchen Code finde ich auch überflüssig, da kann man den Member gleich public machen. Variabeln benenne ich, wie Methoden, im CamelCase bzw PascalCase für Klassen. Member bekommen m, static s und globals g als Prefix. Zwischen Parametern und lokalen Variabeln mache ich keinen Unterschied.

Variabeln so_zu_schreiben finde ich extrem unübersichtlich. Der Unterstrich ,genau wie bei der Variante als Pre- oder Postfix bei Membern, gleicht sehr einem Whitespace, was mir irgendwie das Lesen von Ausdrücken doch erschwert.

[GetSetWilly]

Kleiner Zusatz, ich programmiere nicht im Team. Mein Job hat auch nichts mit der IT zu tun, dafür reicht mein Bildungsstand(Hauptschule) nicht aus. Ich bin halt ein Arbeiter mit viel Gebuckel und dafür wenig Geld, aber einer glücklichen Familie.

[GetWetSilly]

GetSetWilly schrieb:

Kleiner Zusatz, ich programmiere nicht im Team. Mein Job hat auch nichts mit der IT zu tun, dafür reicht mein Bildungsstand(Hauptschule) nicht aus. Ich bin halt ein Arbeiter mit viel Gebuckel und dafür wenig Geld, aber einer glücklichen Familie.

Kann man ohne einem Papier, auf dem ein wenig was draufsteht, nicht in der IT arbeiten?

[randa]

SeppJ schrieb:

randa schrieb:

Wenn ich welche schreibe orientiere ich mich am Stil der standardbibliothek.

void value(int);
int value();

Du meinst so wie ios::rdstate() const und ios::setstate(iostate) ? Oder doch eher so wie ios::width() const und ios::width(streamsize) ? Also ganz konsistent und einheitlich?

ich wusste nicht dass std inkonsistent ist.
Der Stil hat mich jedenfalls überzeugend. Ich kann setx()/getx() schon gar nicht mehr lesen.

[asc]

GetSetWilly schrieb:

Mein Job hat auch nichts mit der IT zu tun, dafür reicht mein Bildungsstand(Hauptschule) nicht aus.

Das ist kein Argument gegen einen IT-Job, wohl aber eine starke Einstiegshürde (und sicherlich auch ein Garant für ein niedriges Einstiegsgehalt).

[GetSetWilly]

Ach, ob sein Hobby zum Beruf machen immer so das Beste ist? Ich verdrahte beruflich Schaltschränke und privat befasse ich mich halt seit Jahren mit verschiedenen Programmiersprachen und Informatik im Allgemeinen. Das ist ein schöner Ausgleich zum Job. Mein Job an sich ist nicht spannend, aber ich bekomme viel Lob und die Kollegen sind auch klasse. Das ist viel wichtiger als ein Job in der IT-Branche oder mehr Geld. Ich komme und gehe halt zufrieden zur Arbeit, Überstunden gibt es nicht und ein Firmenhandy brauche ich auch nicht. Ich kenne nämlich einige aus der IT-Branche und was die immer gestresst wirken...Nein danke. Was bringen mir mehr Statussymbole und vielleicht ein eigenes Haus, wenn ich es nicht genießen kann, weil ich keine Zeit mehr habe und wenn ich Zeit habe, bin ich so gestresst, dass meine Familie leidet...Nein danke.

[hustbaer]

@GetSetWilly

Klingt super was du schreibst - wenn ich in deiner Situation wäre würd ich auch nicht auf IT Job umschwenken.
Vor allem da auch die Gefahr gross ist dass du dir dadurch Programmieren als Hobby kaputt machst.

Worst case hast du dann nen Job der dir noch weniger Spass macht als der aktuelle, und hobbymässig programmieren macht auch keinen Spass mehr, weil du damit schon so viel in der Arbeit zu tun hast.

[hustbaer]

randa schrieb:

Der Stil hat mich jedenfalls überzeugend. Ich kann setx()/getx() schon gar nicht mehr lesen.

IMO sollte man sich nicht nach der STL richten, sondern nach dem was in der Community verbreitet ist.
Und wenn man sich Open-Source Libraries anguckt, dann verwenden die meisten setx/getx (bzw. SetX/GetX).

Ich z.B. muss immer mit den Augen rollen wenn ich .x() bzw. .x(newX) irgendwo lese. Riecht für mich immer nach "trying to be cute".

[Nathan]

hustbaer schrieb:

Ich z.B. muss immer mit den Augen rollen wenn ich .x() bzw. .x(newX) irgendwo lese. Riecht für mich immer nach "trying to be cute".

Naja, da ist aber auch ein Unterschied zwischen .x() und .get_x() (oder .getX()).
Ersteres beschreibt eine Eigenschaft. Es liefert .x() einer Klasse. Beispielsweise .size() gibt die Größe von etwas zurück. Das kann eine Variable sein, die das trackt, eine Schleife sein, die das irgendwie berechnet oder sonst irgendetwas.
.get_x() sagt etwas spezifischeres. Es ist ein Getter einer Variable. Bespielsweise .get_allocator(). Jeder weiß, dass ein Container einen Allocator hat, die Funktion liefert den zurück. Dasgleiche mit get_deleter. allocator() sagt nicht ganz dasselbe aus.
Der Unterschied ist subtil, aber da ist einer. Ich verwende .get_x() als Getter für bestimmte Untervariablen, die byDesign vorhanden sind, .x() hingegen liefert einfach die Eigenschaft x zurück.