Name von Getter und Setter

Eben, so würde ich es auch machen.. ! Aber dadurch dass ich schon laange in C# programmiere, und c++ länger nicht mehr angefasst habe, würde ich schon rein instinktiv mit vielen gettern/settern arbeiten, da ich ja aus c# "Properties" gewöhnt bin:)

Nathan

NullBockException schrieb:

Eben, so würde ich es auch machen.. ! Aber dadurch dass ich schon laange in C# programmiere, und c++ länger nicht mehr angefasst habe, würde ich schon rein instinktiv mit vielen gettern/settern arbeiten, da ich ja aus c# "Properties" gewöhnt bin:)

Ja, aber das ist die klassische Getter/Setter Diskussion:
Bei Klassen mit Memberfunktionen, brauchen nur manche Membervariablen Getter und noch weniger Setter, viel wichtiger sind "normale" Funktionen.
Wenn du für jede Variable Getter und Setter hast, ist es meistens besser daraus eine struct zu machen und alle Variablen öffentlich.

wenn man allzuviele getter und setter braucht, ist das für mich ein Indiz, über die Objekt-Modellierung nachzudenken und ggf zu refaktorisieren.

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?

@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.

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.

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.

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.

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).

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.