Argumente in Konstruktoren, die mit Feldern übereinstimmen

584
Alexandru

Was halten Sie von Argumenten in Konstruktoren, die mit Mitgliedern übereinstimmen, wie im folgenden Beispiel?

public Join(final int parent, final TIntHashSet children) {
  this.parent = parent;
  this.children = children;
}

Ich finde das ärgerlich, da ich verwenden muss this.und auch einige Codeüberprüfungsanwendungen erzeugen Warnungen.

Antworten
7
Ich bin nicht sicher, ob diese Frage wirklich zur Codeüberprüfung passt, aber unten habe ich trotzdem eine Antwort gegeben. greatwolf vor 9 Jahren 3
Dies ist etwas mehr für Programmierer.SE als für hier. Mark Loeser vor 9 Jahren 1
Ich habe das Gefühl, dass die Frage für Code Review gilt: Wird derselbe Name für Argumente und Member verwirrend verwendet? Ist es lesbar? Eric Bréchemier vor 9 Jahren 2

6 Antworten auf die Frage

13
MattGrommes

Ich persönlich fand die _parentungarischen Notationsbriefe immer viel hässlicher als nur zu sagen this. thisist sehr unkompliziert, besonders wenn jemand anderes Ihren Code liest. Wenn ich den Code eines anderen erben und ihn verwenden, ändere ich ihn sofort.

Ich persönlich mag keine Bezeichner, die mit _ beginnen, da die Regeln in C ++ für deren Verwendung nicht trivial sind (OK, es ist trivial, wenn Sie die Regeln kennen, aber die meisten Leute nicht). Obwohl es sich bei dieser Frage um Java handelt, verwende ich dieselbe Regel, um Code über Sprachen hinweg einheitlicher zu machen. Martin York vor 9 Jahren 1
Welche Compiler-Diagnose wird generiert, wenn der Parameter falsch geschrieben wird? Wenn man den Konstruktorparameter NewWhatevr aufruft, schlägt "Whatever = NewWhatever" fehl; Wenn man es Whatevr nennt, dann ist "this.Whatevr = Whatever" legitimer, aber fehlerhafter Code. supercat vor 9 Jahren 0
5
Martin York

Persönlich benutze ich die natürlichsten Namen für Mitgliedsvariablen.
Dies ist so, weil dies diejenigen sind, die Sie am häufigsten verwenden werden (daher mag ich das m_-Präfix nicht).

Für Dinge, die weniger häufig vorkommen (wie Parameter in Konstruktoren), verkürze ich sie oder füge p_ hinzu, je nach Kontext und welches am besten geeignet ist.

Ich habe festgestellt, dass die meisten Java-Codierungsstandards, denen ich begegnet bin, die Verwendung von (im Konstruktor) zu bevorzugen scheinen

this.member = member;

Ich persönlich mag das nicht (aber halte mich immer an die Kodierungsstandards), da es sich fehleranfälliger anfühlt. Ich mag eindeutige Namen für alle Bezeichner (überlappende Namen führen zu leichteren Fehlern). Ich denke auch, dass verschiedene Identifikatoren es einfacher machen, geringfügige Fehler (für den Menschen) zu erkennen.

this.member = p_member;

Das kann ich nicht falsch verstehen, da jede Kennung eindeutig ist.

4
Kayla Nimis

Wenn Sie Zugriff auf eine Kopie von "Clean Code" haben, gibt es ein Kapitel mit dem Namen "Bedeutungsvolle Namen", mit dem ich einverstanden bin. Unterm Strich sollte Ihr Name genau bezeichnen, worauf er sich bezieht. Das Erstellen einer Codierung für den Namen a la C ++ verlangsamt nur das Lesen und führt dazu, dass Devs es ohnehin überspringen. Auch Ihre Idee, sei es Eclipse, Emacs usw., sollte Hervorhebungen bieten, die den Unterschied zwischen Klassenvariablen und Parametern ausmachen.

4
David Hosier

Meiner Meinung nach sollte das, was Sie haben, der bevorzugte Weg sein, Dinge zu tun. In erster Linie sind die Namen der Eingabeparameter die, die in Javadocs angezeigt werden, und sollten daher keine Präfix- oder Albernamen enthalten, die die Javadocs kryptisch machen. Zweitens: Wenn die Namen der Eingabeparameter eindeutig definieren, worum es sich handelt, warum sollen dann die globalen Variablen etwas anderes benannt werden, das den Rest des Codes weniger sinnvoll oder schwieriger zu warten macht? Drittens ist der Umfang der Eingabeparameter so begrenzt, dass es mir scheint, dass Sie dies selten als fehleranfällig empfinden würden, insbesondere wenn Sie einfach Klassendaten initialisieren.

Sie haben einen gültigen Punkt, dessen Namen in Java-Dokumenten angezeigt werden. Alexandru vor 9 Jahren 1
2
greatwolf

Wenn Sie sich Sorgen machen, die zusätzlichen Zeichen thiseinzugeben, können Sie den in C ++ verwendeten Codierungsstil berücksichtigen. Um Mehrdeutigkeiten zwischen Klassendaten und Parametern, die an eine Methode übergeben werden, zu vermeiden, verwende ich normalerweise eine der folgenden Namenskonventionen für Datenmitglieder: m_parentund m_children(Präfix m gibt member an) parent_und children_und myParentund myChildren.

Ich werde Ihre Ideen berücksichtigen. Da ich `this 'hauptsächlich in Konstruktoren und Setters verwende, finde ich, dass es nicht mit dem Rest meines Codes übereinstimmt. Alexandru vor 9 Jahren 0
1
Eva

Ich würde mit Ihrem ersten Instinkt beginnen, ihnen andere Namen zu geben, aber nur, wenn die verschiedenen Namen Sinn machen. Keine ungarische Notation! (Ich habe gelernt, was für ein Chaos das war. Warum empfehlen so viele Style Guides es noch?) Ich verwende in solchen Situationen häufig andere Namen

public Leaf(Color initialColor) {
    color = initialColor;
}

Wenn die beiden Variablen dasselbe repräsentieren und keinen anderen aussagekräftigen Namen haben, ist das thisSchlüsselwort der richtige Weg.