Stil-Frage: this-Referenz

[Mr. M]

Hallo,

ich habe eine Stil-Frage zu Java bzgl. der this-Referenz. Sollte ich this innerhalb einer Klasse immer benutzen, oder nur wenn es nötig ist, z.B. bei Zuweisungen?

Beispiel:

	public Player(int x, int y) {
		this.x = x;
		this.y = y;
	}

	public int getX() {
		return this.x;
	}

Beim Konstruktor ist die Sache eindeutig, aber wie sieht es mit der Methode aus? this ist nicht nötig, sollte man es auf Grund des Stils trotzdem verwenden -- oder gerade nicht?

Danke schon einmal.

 

[meez]

Mich nervts eher, wenn zuviel this steht...Aber das ist wohl tatsächlich Geschmakssache...

 

[Leroy42]

oder gerade nicht?

:applaus: :applaus: :applaus:

 

[Mr. M]

Hmm, ich hätte da gerne ein Machtwort in Form einer Code Convention oder so (erfahrene Programmierer gelten auch ^^). :wink: Was ist objektiv betrachtet der bessere Stil?

 

[Wildcard]

Ich hab lieber nicht zu viel this, aber es ist tatsächlich Geschmacksache

 

[meez]

oder gerade nicht?

:applaus: :applaus: :applaus:

Soviel Geschmack hät ich dir gar nicht zugetraut... :bae:

 

[meez]

Hmm, ich hätte da gerne ein Machtwort in Form einer Code Convention oder so (erfahrene Programmierer gelten auch ^^). :wink: Was ist objektiv betrachtet der bessere Stil?

Sind wir nicht erfahren genug :bahnhof: .... Wie auch immer; Objektiv betrachtet kein this, weil es den Code unnötig vergrössert und auch die .class Files....

 

[L-ectron-X]

http://java.sun.com/docs/codeconv/html/CodeConvTOC.doc.html

 

[Guest]

Okay, Danke! Damit hat sich die Frage erledigt und ich bin zufrieden. :wink:

 

[Wildcard]

Wie auch immer; Objektiv betrachtet kein this, weil es den Code unnötig vergrössert und auch die .class Files....

Das Gegenargument ist, das this klarer herausstellt das man auf eine Instanzvariable zugreift.
Theoretisch wiegen sich beide Argumente auf, in den Zeiten moderner IDEs halte ich zweiteres aber für obsolete.

 

[Leroy42]

Der Gebrauch unnötiger this regt mich fast so auf wie
diese unäglichen Vergleiche auf true/false

boolean paintGrid = true;
...
if (paintGrid == true) {
    paintGrid();
}

Schließlich kommt doch auch kein Mensch auf die
Idee soetwas wie

if (a<b == true)

zu schreiben. :x

 

[Leroy42]

Das Gegenargument ist, das this klarer herausstellt das man auf eine Instanzvariable zugreift.

Wer Methoden fabriziert bei denen es nicht sofort ersichtlich ist,
ob es sich bei Zugriffen um lokale Variablen handelt oder nicht,
hat von Haus aus etwas falsch verstanden.

 

[Wildcard]

Die Argumentation bezieht sich nicht nur auf lokale Variablen.
Da gibt's auch noch vererbte protected, friendly und public Variablen :wink:

 

[Leroy42]

Die Argumentation bezieht sich nicht nur auf lokale Variablen.
Da gibt's auch noch vererbte protected, friendly und public Variablen :wink:

Wenn eine Klasse von einer anderen erbt, dann gehören
für mich die mitgeerbten Member zu der erbenden Klasse.

Anders gesagt: Ich will gar nicht wissen, ob ich auf ein Member
der eigenen Klasse oder einer ihrer Superklassen zugreife.

Seit wann gibt es in Java friendly-Variablen :shock: :autsch:

 

[Wildcard]

Seit wann gibt es in Java friendly-Variablen :shock: :autsch:

Wenn dir default lieber ist :roll:

 

[Leroy42]

Seit wann gibt es in Java friendly-Variablen :shock: :autsch:

Wenn dir default lieber ist :roll:

Meinst du jetzt package-default?
Diese gehören doch entweder der eigen (Super)Klasse an oder
sie müssen mit einer Instanz der Klasse (der Klasse selbst)
gecontexted werden. (Keine Ahnung wie der korrekte Begriff hierfür ist)

 

[Wildcard]

Ich hab ehrlich keine Ahnung was du mit 'gecontexted' meinst :lol:
Ich meine den 'Modifier ohne Namen' (default)
http://www.uni-bonn.de/~manfear/javaprotection.php

 

[Leroy42]

Genau den habe ich auch vermutet:

package xyz;
class A {
  int a;
}
class B {
  int b;
  void methode(A meinA) {
    b = 19; // Dieselbe Klasse
    meinA.a = 42; // a ist "friendly" muß aber "im Kontext" von meinA aufgerufen werden
  }
}

 

[Wildcard]

Nö. :shock: Du musst nur B von A erben lassen. Ist doch auch klar, das du nicht einfach so auf irgendwelche Variablen im selben package zugreifen kannst ???:L

 

[Leroy42]

Nö. :shock: Du musst nur B von A erben lassen. Ist doch auch klar, das du nicht einfach so auf irgendwelche Variablen im selben package zugreifen kannst ???:L

Ja aber wenn B von A erbt, dann interessiert es mich eben nicht
ob a nun in B deklariert wurde oder in A.

B ist ja ein A. Also gehört B auch alles was A gehört/anbietet/deklariert/...

Wenn eine Klasse von einer anderen erbt, dann gehören
für mich die mitgeerbten Member zu der erbenden Klasse.

Anders gesagt: Ich will gar nicht wissen, ob ich auf ein Member
der eigenen Klasse oder einer ihrer Superklassen zugreife.

 

[Wildcard]

Wie gesagt, ich bin kein Befürworter dieser Schreibweise. Gast hat nach einer objektiven Stellungnahme gefragt und dazu gehört eben die Gegenseite.
Für mich ist es auch transparent ob eine Variable nun von der superklasse kommt oder nicht und gleiche Namen in Vater und Kinderklasse sind nun wirklich daneben, daher halte ich die explizite Unterscheidung auch nicht für notwendig.

 

[Leroy42]

:toll:

 

[byte]

Ich benutze this meistens auf Faulheit, damit der Code Assistent aufgeht und ich das Feld/ die Methode auswählen kann. Später fliegen sie dann aber beim "Clean Up..." wieder raus.

God bless the Eclipse IDE... :bae:

 

[sliwalker]

Wenn ich immer auf den lahmar....en Code-Assistenten warten müsste, würde ich auch anfangen Java als langsam zu bezeichnen

Du schmeisst alle "this" beim "Clean Up..." wieder raus? mutig...

Das Argument, dass die .class-datei größer wird zählt bei mir genauso wenig wie das Argument, dass Abblendlicht bei Tag "ja viel zu teuer" ist. Für mehr "Sicherheit" bzw. für "deutlichen und einheitlichen" Code, würde ich einiges in Kauf nehmen, was vielleicht zu Anfang unbeliebt ist. Ich selbst verwende so wenig "this" wie möglich, kenne aber Gründe es immer zu verwenden. Denn wenn man mal in der misslichen Lage ist, Quelltext mittels Programm zu "korrigieren" wird ein "this" vor jeder Zuweisung einer Klassenvariablen zu schätzen wissen. Selbst erlebt -.-
Klar das da Fehler in der Planung, Entwicklung, whatever, im Vorfeld schon aufgetreten sind, aber wo passiert das nie?

greetz
SLi

 

[byte]

Wenn ich immer auf den lahmar....en Code-Assistenten warten müsste, würde ich auch anfangen Java als langsam zu bezeichnen

Ich weiss ja nicht, was Du für nen Rechner hast, aber ich warte selten auf ihn. Gerade bei bei vielen Methodenparametern gehts damit oft fixer, vor allem seit Eclipse 3.2...

Du schmeisst alle "this" beim "Clean Up..." wieder raus? mutig...

Nicht ich schmeisse sie raus, sondern Eclipse auf Kommando... und natürlich auch nur diejenigen, die unnötig sind.

 

[sliwalker]

Ich weiss ja nicht, was Du für nen Rechner hast, aber ich warte selten auf ihn. Gerade bei bei vielen Methodenparametern gehts damit oft fixer, vor allem seit Eclipse 3.2...

Echt? Springt der bei Dir auf wie nix? Also gerade wenn ich this oder static-Attribute abrufen möchte, dauert es round about 0,5 - 2 Sekunden bis der Assistent aufspringt. Hab auch eclipse 3.2 und mein Rechner ist schon ganz gut, weil ich eben auch gerne mal ein Spielchen zocke.

greetz
SLi

 

[Wildcard]

Linux oder Windows? In Windows wird Eclipse leider sehr aggressiv ausgelagert, was für Eclipse den Performance-Tod bedeutet.

 

[Murray]

Das Argument, dass die .class-datei größer wird zählt bei mir genauso wenig wie das Argument, dass Abblendlicht bei Tag "ja viel zu teuer" ist.

Hat mal jemad ausprobiert, ob überflüssige "this" den Byte-Code überhaupt verändern? Das hätte ich eigentlich nicht erwartet - während das Abblendlicht definitiv zu einem Mehrverbrauch führt, so dass man hier wirklick abwägen muss, was einem die Erkennbarkeit wert ist.

<slightly off-topic>
Ich bewege mich (beruflich) - in einer Welt, in der - abweichend von den Sun-Coding-Conventions - Class-Member mit Großbuchstaben bezeichnet werden, also

class X {
  private Y Z;

 public X( final Y z) {
   Z = z; //-- kein explizites 'this' notwendig
 }

 public doSomething() {
   Z.doABC();
 }

}

OK, man kann so - z.B. in X#doSomething - nicht mehr anhand der Konvention erkennen, ob es sich bei Z jetzt um den
Namen einer Variablen oder um eine Klasse handelt, an der eine (statische) Methode aufgerufen werden soll - aber ist das wirklich wichtiger als die Unterscheidung, ob Z eine lokale Variable oder ein Member ist??
</slightly off-topic>

 

[sliwalker]

Windows. (Spiele)

Wenn Du mit "aggresiv ausgelagert" die Festplatten-Auslagerung, sprich die Nutzung des virtuellen Arbeitsspeicher meinst, trifft das bei mir nicht zu. Die ist bei mir abgeschaltet, genauso wie die Systemwiederherstellung, weil sich in diesem Bereich Viren und derlei Zeug sehr wohl fühlen. Diese Bereiche können auch von Virenscannern nicht eingesehen werden, was das ganze noch schlimmer macht. Wenn ich eclipse starte, dann steht die javaw mit ca 75 MB im Speicher. Auslagerungsdatei wird mir im Taskmanager mit 8 MB angezeigt. Was ich mir nur durch meinen 8MB Festplattencache erklären kann. Naja...ich will mal den Thread nicht entfremden

Moral von der G'schicht,
"this" ohne viel RAM lieber nicht. (Ähhm..ja. Ich geh mal off )

 

[Wildcard]

Überhaupt keine Auslagerungsdatei? :shock:
Naja, dann kann ich's mir nicht erklären, bei mir geht das sehr flott...

 

[TheJavaKid]

also bei so sachen wie wir in der schule machen schreib immer this. aber privat nich... ausser in actionscript, flash xD

 

[byte]

Bei mir (Intel Duo Core, 2GB RAM) ist der Code Assistent eigentlich sofort da.

 

[sliwalker]

Hmmm....
...(Athlon64 4200+ 2GBRAM)...0,5Sek.

Ka.

 

[Roar]

Hmmm....
...(Athlon64 4200+ 2GBRAM)...0,5Sek.

Ka.

hast du vielleicht in den editor einstellungen eingestellt, dass er erst nach 500ms erscheinen soll? :roll:

 

[Ark]

@topic: Ich verwende this nur in settern bzw. in Konstruktoren. In anderen Methoden nehme ich eben andere (meist kürzere) Bezeichner.

MfG
Ark

 

[AlArenal]

Dererlei Diksussionen gibts in manche anderer Sprache wohl nicht. Ruby z.B. verfolgt den Ansatz 'Design by Convention' und schreibt vor wie welche Variablen je nach Scope benannt werden müssen. Da gibts keine Diskussionen und auch keine Umstellung weil Coder A in Projekt 123 es so und Coder 2 in Projekt 234 es anders hält.
Diese gewissermaßen implizite Logik weiß man irgendwann auch zu schätzen, wenn aus der Entscheidungsfreiheit eine Last geworden ist. Gerade für Einsteiger ist vieles sicher einfacher wenn es einfach feste Vorgaben gibt und man nicht 1001 Möglichkeit hat etwas zu handhaben. Es gibt auch diverse Java-Entwickler die Instanzvariablen ein '_' oder sonstwas voranstellen. Habs auch mal probiert und dann doch wieder verworfen.

 

[Guest]

Wie wär's mit sowas?

public class WasAuchImmer implements IWasAuchImmer
{
   public static final int KONSTANTE = 1; 

   private String m_Vorname; // Membervariable mit m_
   
   public WasAuchImmer(String p_Vorname) // Parameter mit p_
   {
      m_Vorname = p_Vorname;

      String v_Vorname = ... // prozedur-lokale Variable mit v_ 
   }
   
   ...
}

Man erkennt dann überall auf den ersten Blick, was, wo definiert ist.

 

[SnooP]

also ich muss auf den code-assist bei eclipse 3.1 auch ca. ne Sekunde warten... und das nervt mich auch (das war bei VisualStudio tatsächlich mal fixer!), aaaaber - ich mach das auch so, weil ich oft vergesse, wie denn die dämlichen Methoden so hießen - und ob ich nicht doch in irgendwas rumcasten muss, was ich vergessen hab .. bin wohl doch nicht soon hacker, wie ich immer dachte
und wenn man viele lokale aber auch objektvariablen in einer Methode benutzt, verwende ich this häufig auch bewusst, für die bessere unterscheidung, auch wenn man das an den Variablennamen erkennen könnte, ist this ein sehr leicht zu erkennendes Schlüsselwort, was das ganze imho dann lesbarer macht.

Diese Unterstrich-Variablen find ich persönlich sehr unschön, aber sowas kommt dann auch immer auf die persönlichen bzw. Team-Codeconventions an. Das kann manchmal schon sinnvoll sein, sowas zu benutzen.

 

[byte]

Ich kann mich mit dieser Unterstrich-Schreibweise aus folgenden Gründen nicht anfreunden:

1. hässlich
2. die deutsche Tastatur zwingt einen schon zu genug Fingerakrobatik beim Coden
3. vernünftiges Syntax-Highlighting setzt Klassenvariablen eh schon farbig ab

Und im Zweifelsfall reicht ja ein einfacher STRG + Klick (in Eclipse) aus, um zur Deklaration zu springen und alle Zweifel zu beseitigen.