Code Conventions?

Hallo,

ich will mich bemühen, sauberen und gut lesbaren Code zu schreiben. Normalerweise setze ich vor Parameter immer ein _ , um deutlich zu machen, dass es "nur" übergebene Parameter sind, also z.B.:

public void setAlter(int _alter) {
    this.alter = _alter;
}

Macht man das so? Eclipse verwendet nämlich keine _ bei der automatischen Methodengenerierung. Dann finde ich es aber nicht so schön, wenn ich Variablen aus verschiedenen Ebenen mit selbem Namen habe.

Dirk Schnelle

Es gibt sicherlich einige, die das so machen. Prinzipiell würde ich dir aber die SUN Coding Conventions nahelegen.

http://java.sun.com/docs/codeconv/

mach an die Membervariable einen _ dran

alter_ = alter;

dann brauch man das this nicht.

Optimizer schrieb:

Was soll denn das mit den Unterstrichen immer? Ist das wirklich soooo schlimm, wenn man wirklich mal ein gleichnamiges Argument übernimmt, was man übrigens vermeiden kann, ein this davor zu schreiben?
Und einen besseren Vorschlag, als sich an die Java-Konventionen zu halten, kann man wirklich nicht machen. Und diese sehen keine derart hässliche Namensgebung vor.

Gregor

Dem kann ich mich eigentlich nur anschließen. Unterstriche sind IMHO Schrott.

Allerdings kann man bei gleichen Namen für Membervariablen und lokale Variablen natürlich schnell mal Fehler machen, die vielleicht nicht auf den ersten Blick zu finden sind. Wie Optimizer aber schon gesagt hat, kann man gleiche Namen auch ohne Unterstriche leicht vermeiden, wenn man denn Probleme damit hat.

stevg

was haben eigendlich alle gegen 'this' ich finde das ist am übersichtlichsten.

Gregor

stevg schrieb:

was haben eigendlich alle gegen 'this' ich finde das ist am übersichtlichsten.

Das Problem beim "this" ist, dass man es vergessen kann, was zu einem Fehler führt, der erst zur Laufzeit auffällt.

Bei mir ergibt es sich meistens, dass Parameter anders heißen als Datenelemente. Und wenn nicht, dann würde ich höchstens dem Paramter ein hässliches Präfix verpassen, weil ich den nur in einem kurzen Kontext verwende.
Die Lösung mit this ziehe ich aber dann vor.

stevg

Gregor schrieb:

stevg schrieb:

was haben eigendlich alle gegen 'this' ich finde das ist am übersichtlichsten.

Das Problem beim "this" ist, dass man es vergessen kann, was zu einem Fehler führt, der erst zur Laufzeit auffällt.

so hab ich das noch gar nicht gesehen - eigenartig dass mir da noch nichts passiert ist, denn ich nutze eigendlich immer this ...

SG1

Gregor schrieb:

stevg schrieb:

was haben eigendlich alle gegen 'this' ich finde das ist am übersichtlichsten.

Das Problem beim "this" ist, dass man es vergessen kann, was zu einem Fehler führt, der erst zur Laufzeit auffällt.

Wobei ein vernuenftiger Compiler bei

foo = foo;

doch warnen sollte, oder?

stevg

SG1 schrieb:

Gregor schrieb:

stevg schrieb:

was haben eigendlich alle gegen 'this' ich finde das ist am übersichtlichsten.

Das Problem beim "this" ist, dass man es vergessen kann, was zu einem Fehler führt, der erst zur Laufzeit auffällt.

Wobei ein vernuenftiger Compiler bei
foo = foo;
doch warnen sollte, oder?

mag sein, es gibt aber auch fälle in denen du mit foo etwas rechnest:

x = Math.pow(this.foo, a);
x = Math.pow(foo, a); // this vergessen

und hier zu warnen macht wenig sinn.

und ich denke diese situation ist eine häufigere fehlerursache als "foo = foo;"

SG1

stevg schrieb:

x = Math.pow(this.foo, a);
x = Math.pow(foo, a); // this vergessen
und hier zu warnen macht wenig sinn.

und ich denke diese situation ist eine häufigere fehlerursache als "foo = foo;"

Es ging um Getter- und Setter-Methoden, oder? Bei allen anderen stellt sich das Problem der gleichen Variablen doch gar nicht.

In der Tat, in welcher Methode übergibt man schon ein Argument, dass wie ein Datenelement heisst?

CengizS

Durch die Eindeutigkeit der get- bzw. set-Methoden empfehle ich stets den selben Variablennamen in der Methodensignatur zu verwenden - nämlich newValue bzw newObject. Dies wird auch von den meisten fireXYZEvent()-Methoden im JDK gemacht und hilft dabei zuverlässig den Problemen der Nomenklatur aus dem Weg zu gehen. Die Benutzung von this halte ich für Geschmackssache - es ist möglich, also warum auch nicht nutzen? Viel wichtiger halte ich es, einen Standard anzunehmen und den dann auch konsequent durchzuziehen.

Beispiel:

public class MyHyperClass
{
    int hyperLimit;
    Object dataObject = null;
    ...

    public MyHyperClass() {
        ...
    }

    public int getHyperLimit() {
        return hyperLimit;
    }

    public void setHyperLimit(int newValue) {
        hyperLimit = newValue;
    }

    public Object getDataObject() {
        return dataObject;
    }

    public void setDataObject(Object newObject) {
        if (newObject != null)
            dataObject = newObject;
    }

    ...
}

Bashar

Konstruktoren und Setter

CengizS

Probleme mit der Artikulation? "Was will uns diese Werbesendung sagen?"

Bashar

Guck auf die Zeiten, zu denen wir gepostet haben.

Bashar schrieb:

Konstruktoren und Setter

Da haben wir ja schon festgestellt, das die Verwendung von this nicht verwirrend sein sollte.