# Stil-Frage: this-Referenz



## Mr. M (1. Dez 2006)

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 (1. Dez 2006)

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


----------



## Leroy42 (1. Dez 2006)

Mr. M hat gesagt.:
			
		

> oder gerade nicht?



 :applaus:  :applaus:  :applaus:


----------



## Mr. M (1. Dez 2006)

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 (1. Dez 2006)

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


----------



## meez (1. Dez 2006)

Leroy42 hat gesagt.:
			
		

> Mr. M hat gesagt.:
> 
> 
> 
> ...



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


----------



## meez (1. Dez 2006)

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?



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 (1. Dez 2006)

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


----------



## Guest (1. Dez 2006)

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


----------



## Wildcard (1. Dez 2006)

meez hat gesagt.:
			
		

> 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 (1. Dez 2006)

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 (1. Dez 2006)

Wildcard hat gesagt.:
			
		

> 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 (1. Dez 2006)

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


----------



## Leroy42 (1. Dez 2006)

Wildcard hat gesagt.:
			
		

> 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 (1. Dez 2006)

Leroy42 hat gesagt.:
			
		

> Wildcard hat gesagt.:
> 
> 
> 
> ...


----------



## Leroy42 (1. Dez 2006)

Wildcard hat gesagt.:
			
		

> Leroy42 hat gesagt.:
> 
> 
> 
> ...


----------



## Wildcard (1. Dez 2006)

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 (1. Dez 2006)

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 (1. Dez 2006)

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 (1. Dez 2006)

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



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.


----------



## Wildcard (1. Dez 2006)

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 (1. Dez 2006)

:toll:


----------



## byte (1. Dez 2006)

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 (1. Dez 2006)

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 (1. Dez 2006)

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



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 (1. Dez 2006)

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



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 (1. Dez 2006)

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


----------



## Murray (1. Dez 2006)

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.


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 (1. Dez 2006)

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 (1. Dez 2006)

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


----------



## RawBit (1. Dez 2006)

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


----------



## byte (1. Dez 2006)

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


----------



## sliwalker (1. Dez 2006)

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

Ka.


----------



## Roar (1. Dez 2006)

sliwalker hat gesagt.:
			
		

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


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


----------



## Ark (1. Dez 2006)

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

MfG
Ark


----------



## AlArenal (1. Dez 2006)

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 (2. Dez 2006)

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 (2. Dez 2006)

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 (2. Dez 2006)

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.


----------

