Methodennamen für Getter und Setter


  • Administrator

    isrichtig schrieb:

    Dieser Glaubenskrieg ist nicht von Leuten wie mir gemacht, das ist einfach menschlich.

    Doch, denn mit solchen Aussagen machst du genau das:

    isrichtig schrieb:

    ... ganz alter Tobak und gilt als überholt.

    isrichtig schrieb:

    Aber die alten Hasen wirste wohl nicht mehr umstimmen können.

    isrichtig schrieb:

    ..., aber die sterben ja auch irgendwann aus 😃

    Es ist nicht veraltet. Es wird nicht nur von alten Hasen eingesetzt. Es ist nur eine Frage des subjektiven Geschmackes.

    @thenewone,
    Bekannte Pre- und Postfixe für Membervariablen sind:

    _a
    m_a
    a_
    a_m
    

    In Boost und den Beispielen im Standard wird, glaube ich, aktuell vor allem die dritte Version eingesetzt, falls das irgendwie von belang sein sollte.

    Grüssli



  • Ja das war meine subjektive Meinung. Es gibt viel zu wenig Leute die nicht zu ihrer Meinung stehen, ich tue dies und hier herrscht ja wohl Meinungsfreiheit.

    Klar ist ja wohl auch dass jedes Posting die Meinung der Person dahinter widerspiegelt. Und ich bin auch fest der Meinung das Coding Conventions Glaubenskriege sind wie: OS, Grafikkarte, Programmiersprachen, große Brüste kleine Brüste usw... Besser auf einer Seite stehen als immer zwischen den Stühlen springen, so etwas ist charakterlos und ein Zeichen großer Unsicherheit.

    Ich habe meine Meinung vielleicht etwas hart formuliert aber deswegen ist es nicht mehr oder weniger ein Glaubenskrieg. Ich toleriere ja auch andere Conventions, aber sorry als ich das mit dem GetA() gesehen habe hätte sich jedes Topmodel gefreut was auch so ohne Finger raus kommt.



  • Hmm, wie ich es in C++ machen würde, weiß ich nicht. Getter und Setter kommen bei mir selten vor, weil ich der Ansicht bin, ich sollte der Klasse eher Nachrichten schicken, was sie zu tun hat, anstatt Memberdaten von ihr anzufordern. Natürlich gibts auch Anwendungsgebiete für Getter und Setter, z. B. um Daten im Backend synchron zu halten, so wie bei ORMs, aber solche Sachen musste ich in letzter Zeit nicht schreiben 😉

    Interessanter wirds bei einer Sprache wie Ruby, bei der Funktionsaufrufe keine (bzw. nur selten) Klammern brauchen:

    class Foo
      def bar
        # @bar ist eine Membervariable
        return @bar    # Das Wort "return" ist hier nicht nötig und auch unüblich
      end
    
      def bar=(new_value)
        @bar = new_value
    end
    
    foo = Foo.new
    foo.bar = 42
    puts foo.bar
    

    Was so aussieht, als würde ich direkt eine Membervariable manipulieren, sind in Wahrheit zwei Funktionsaufrufe. In Ruby bevorzuge ich also eindeutig diese Variante und sie ist auch üblich, um nicht zu sagen Quasistandard.



  • @isrichtig:

    Ja das war meine subjektive Meinung
    (...)
    Ich toleriere ja auch andere Conventions

    Nein, tust du nicht.

    Eine Formulierung wie "X ist ganz alter Tobak und gilt als überholt" ist absolut und lässt keine Interpretation zu wo es nur "deine Meinung" ist.



  • Es ist ein schmaler Grat zwischen Standhaftigkeit und Borniertheit. Auch habe ich, so wie du das Recht hast, deine Meinung zu äußern, das Recht, zu äußern, dass ich deine Meinung für bescheuert halte. Soviel zum Thema Meinungsfreiheit.

    Was Namenskonventionen angeht, so sind diese von untergeordneter Bedeutung. Die Struktur des Programms hängt nicht davon ab, ob die Klasse jetzt class_name oder ClassName heißt, und solange man die Namen nicht völlig verblödet wählt, leidet die Verständlichkeit des Codes nicht unter der einen oder anderen Konvention.

    Ich halte das ganze sprachabhängig, will sagen, ich benenne meine APIs so, wie ich annehme, dass ein anderer Programmierer derselben Sprache davon nicht sonderlich überrascht wäre. Ich verliere aber keinen Schlaf, wenn ich ein API zu benutzen habe, das sich anders verhält - es gibt Dinge, über die es sich nicht zu streiten lohnt.



  • Also ich benutze die Präfixe get_ und set_ für meine Getter/Setter. Das habe ich mir im Laufe der Zeit so angewöhnt, merke aber sehr oft, dass die meisten Programmierer zu anderen Möglichkeiten greifen.



  • Das Übel der set/get-Präfixe kommt aus der Java-Welt. Und dort hat es technische Gründe: wenn man Java-Beans serialisieren will. Es ist aber selbst in Java keine Pflicht in anderen Fällen ein set/get als Präfix zu nutzen.

    Dieses Übel hat sich dann in die restliche Welt ausgetragen, obwohl Java selbst diese Anforderung nur in einem speziellen Fall hat.



  • hustbaer schrieb:

    @isrichtig:

    Ja das war meine subjektive Meinung
    (...)
    Ich toleriere ja auch andere Conventions

    Nein, tust du nicht.

    Eine Formulierung wie "X ist ganz alter Tobak und gilt als überholt" ist absolut und lässt keine Interpretation zu wo es nur "deine Meinung" ist.

    Ich tollerie sehr wohl das einige Dödels vor jeder Methode ein get oder set davor schreiben müssen obwohl total klar ist worum es sich handelt. Wie wäre es denn mit dem Präfix int WithThisMethodYouWillGetTheValueX() anstatt int x() und void WithThisMethodYouWillSetTheValueOfX(int x) anstelle von void x(int x). So könnte auch die Zeichbreite bei Full HD voll ausgenutzt werden, weil man ja auch dort alles in Fullscreen machen muss. *kopfklatsch

    Ich toleriere auch vollgepisste Penner auf der Straße, muss ich sie deswegen mögen? 😕



  • Wenn man etwas toleriert, impliziert das autom. das man es nicht mag. Sonst bräuchte man es ja nicht tolerieren.



  • orientiere dich einfach am generellen standard der sprache. wenn bei der sprache/framework deiner wahl die funktionsbibliothek z.B. GetX und SetX schreibt, dann mach es auch so. sonst sieht hinter alles durcheinander aus, obwohl es unbeabsichtigt war.



  • Was soll denn so verkehrt an get_ set_ sein als Präfix?

    Synergiert doch prächtig mit der InteliSense Funktion des Compilers und hilft daher jemanden der deine Klasse nicht kennt sich schnell zurecht zu finden.

    einfach .g schreiben und schon sieht man alle Werte die man abrufen kann untereinander stehen..

    Mein Rat: Sprich dich mit den Kollegen ab die deine Klasse nutzen werden und wenn das nur du bist, dann mach was du willst 😃



  • @isrichtig:
    Sorry! Du hast natürlich vollkommen Recht, weil du ja die Weisheit mit dem Löffel gefressen hast.
    Also wenn du meinst dass alles andere doof ist, dann muss das natürlich auch so sein. Und wer anders denkt ist klarerweise einfach nur doof.

    Hatte ich erst nicht bedacht.

    Manchmal bin ich halt auch sehr doof 🙄



  • Man könnte es auch so zusammenfassen: Rhabarber Rhabarber Rhabarber Rhabarber Rhabarber Rhabarber Rhabarber Rhabarber Rabe.



  • thenewone schrieb:

    Hallo,

    ich würde gerne meine Getter und Setter wie in dem Beispiel hier benennen, aber das geht ja leider nicht. Welche Bezeichner verwendet ihr denn in euren Klassen?

    class foo{
      int a;
    public:
      foo(int a = 0) : a(0) {}
      ~foo() {}
      void a(int a) { this->a = a; } // Setter
      int a() const { return a; }    // Getter
    };
    

    Lösung: Mitglieder einen Präfix geben.
    Bei mir würde das so aussehen:

    class foo
    {
    public:
      foo(int a1) : m_a(a1) {}
      ~foo() {}
    
       void a (int a) { m_a = a; }
       int a() const { return m_a; }
    private:
       int m_a;
    

    rya.



  • hustbaer schrieb:

    @isrichtig:
    Sorry! Du hast natürlich vollkommen Recht, weil du ja die Weisheit mit dem Löffel gefressen hast.

    Habe ich nie behauptet.

    hustbaer schrieb:

    Also wenn du meinst dass alles andere doof ist, dann muss das natürlich auch so sein.

    In diesem einen Punkt ja. Ich darf andere Meinungen doof finden und die get und set Präfixe finde ich extrem doof, und nun 😕

    hustbaer schrieb:

    Und wer anders denkt ist klarerweise einfach nur doof.

    Habe ich auch nie behauptet, sondern einige Methoden von anderen finde ich doof.

    hustbaer schrieb:

    Hatte ich erst nicht bedacht.
    Manchmal bin ich halt auch sehr doof 🙄

    Ob du doof bist kann ich nicht sagen, ich kenne dich nicht. Deine Schlussfolgerungen waren es jedenfalls.


Anmelden zum Antworten