Stil-Frage: this-Referenz

  • Themenstarter Themenstarter Mr. M
  • Beginndatum Beginndatum
Status
Nicht offen für weitere Antworten.
M

Mr. M

Gast
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:
Code: 
	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.
 
Mich nervts eher, wenn zuviel this steht...Aber das ist wohl tatsächlich Geschmakssache...
 
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?
 
Mr. M hat gesagt.:
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?
Zum Vergrößern anklicken....

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....
 
Okay, Danke! Damit hat sich die Frage erledigt und ich bin zufrieden. :wink:
 
meez hat gesagt.:
Wie auch immer; Objektiv betrachtet kein this, weil es den Code unnötig vergrössert und auch die .class Files....
Zum Vergrößern anklicken....
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.
 
Der Gebrauch unnötiger this regt mich fast so auf wie
diese unäglichen Vergleiche auf true/false
Code: 
boolean paintGrid = true;
...
if (paintGrid == true) {
    paintGrid();
}

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

Code: 
if (a<b == true)
zu schreiben. :x
 
Wildcard hat gesagt.:
Das Gegenargument ist, das this klarer herausstellt das man auf eine Instanzvariable zugreift.
Zum Vergrößern anklicken....

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. 😎
 
Die Argumentation bezieht sich nicht nur auf lokale Variablen.
Da gibt's auch noch vererbte protected, friendly und public Variablen :wink:
 
Wildcard hat gesagt.:
Die Argumentation bezieht sich nicht nur auf lokale Variablen.
Da gibt's auch noch vererbte protected, friendly und public Variablen :wink:
Zum Vergrößern anklicken....

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 hat gesagt.:
Leroy42 hat gesagt.:
Wildcard hat gesagt.:
Seit wann gibt es in Java friendly-Variablen :shock: :autsch:
Zum Vergrößern anklicken....
Wenn dir default lieber ist :roll:
Zum Vergrößern anklicken....
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)
Zum Vergrößern anklicken....
 
Genau den habe ich auch vermutet:
Code: 
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
  }
}
 
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
 
Wildcard hat gesagt.:
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
Zum Vergrößern anklicken....

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

Leroy42 hat gesagt.:
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.
Zum Vergrößern anklicken....
 
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.
 
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:
 
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
 
sliwalker hat gesagt.:
Wenn ich immer auf den lahmar....en Code-Assistenten warten müsste, würde ich auch anfangen Java als langsam zu bezeichnen 🙂
Zum Vergrößern anklicken....

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...😉
Zum Vergrößern anklicken....

Nicht ich schmeisse sie raus, sondern Eclipse auf Kommando... und natürlich auch nur diejenigen, die unnötig sind.
 
byto hat gesagt.:
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...
Zum Vergrößern anklicken....

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
 
Linux oder Windows? In Windows wird Eclipse leider sehr aggressiv ausgelagert, was für Eclipse den Performance-Tod bedeutet.
 
sliwalker hat gesagt.:
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.
Zum Vergrößern anklicken....
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
Code: 
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>
 
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 🙂 )
 
Überhaupt keine Auslagerungsdatei? :shock:
Naja, dann kann ich's mir nicht erklären, bei mir geht das sehr flott...
 
also bei so sachen wie wir in der schule machen schreib immer this. aber privat nich... ausser in actionscript, flash xD
 
@topic: Ich verwende this nur in settern bzw. in Konstruktoren. In anderen Methoden nehme ich eben andere (meist kürzere) Bezeichner. 😉

MfG
Ark
 
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.
 
Wie wär's mit sowas?
Code: 
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.
 
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.
 
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.
 
Status
Nicht offen für weitere Antworten.

Aktuelle Jobs

Neue Themen

Ähnliche Themen

Referenz auf Referenz
Antworten: 3
Zugriff auf Instanzvariablen, Frage zum guten Stil
Antworten: 2
Stil ? - ....Nein nicht das Ende des Besens ^^
Antworten: 11
Code Quality und Stil
Antworten: 5
Schlechter Stil
Antworten: 8

Zurück
Oben