this

[fanta5]

public class Klasse {
private int var1 = 0;

	public void tu_was(AndersObjekt anderesObjekt) {
		var1++;
	}
}

Normalerweise hätte ich gedacht, dass ich this.var1++; hätte notieren müssen.

1.) Verstehe ich das richtig, daß der Compiler zuerst in der Methode nach der Variablen "var1" sucht und wenn er sie dort nicht findet, sofort in der Klasse nach einer entsprechenden Instanzvariablen sucht?

2.) Würde es dennoch Sinn machen, this.var1++; zu notieren, um immer im Blick zu haben (zumindest bei längeren Methoden), daß man die Instanzvariable hochzählt?

f5

 

[Thallius]

Ja und Ja

Gruß

Claus

 

[fanta5]

Ja und Ja

Gruß

Claus

Danke und Danke,

f5

 

[Dompteur]

2.) Würde es dennoch Sinn machen, this.var1++; zu notieren, um immer im Blick zu haben (zumindest bei längeren Methoden), daß man die Instanzvariable hochzählt?

Nein.
Wenn man selbstverständliches hinschreibt, macht das den Code länger, aber nicht klarer.
IDEs wie Eclipse können Instanzvariablen und lokale Variablen mit unterschiedlichen Farben darstellen.

Wenn deine Methode zu lang ist und du sie nicht mehr überblicken kannst, dann solltest du sie eher überarbeiten.

 

[fanta5]

Nein.
Wenn man selbstverständliches hinschreibt...

Hm. Ja was denn nun? this rein oder nicht rein, das ist hier die Frage :shock:

Wenn deine Methode zu lang ist und du sie nicht mehr überblicken kannst, dann solltest du sie eher überarbeiten.

Darum gehts doch nicht. Es ist doch eine rein hypothetische Frage gewesen...

f5

 

[Thallius]

Es gibt überhaupt keine Nachteile wenn man this schreibt. Es gibt nur Vorteile. Es ist einfach sauberer und weniger fehlerträchtig wenn man es schreibt.
Das eine IDE es farblich kennzeichnet ob es sich um eine lokale oder eine Instanzvariable handelt ist echt kein Argument. Es soll auch Leute geben die benutzen noch den vi zum editieren....

Gruß

Claus

 

[Dompteur]

Es gibt überhaupt keine Nachteile wenn man this schreibt. Es gibt nur Vorteile. Es ist einfach sauberer und weniger fehlerträchtig wenn man es schreibt.

Manche sehen es als Nachteil, wenn sie mehr tippen müssen oder die Zeilen unnötig länger werden. ;-)
Das Beispiel mit dem vorangestellten "this." ist ja nur eines der Beispiele, die Code unnötig aufblasen. Andere Beispiele sind unnötige Klammern, nichtsagende Kommentare, usw.
Wenn man professionell Software entwickelt, dann versucht man eben auch Zeitfresser zu vermeiden.
Da stellt sich die Frage: Will man einen kompakten, klaren Code oder einen längeren mit Redundanzen? Wenn man seinen Code mit Selbstverständlichkeiten spickt, dann braucht man später auch entsprechend länger, diesen wieder zu verstehen.

Darum gehts doch nicht. Es ist doch eine rein hypothetische Frage gewesen...

Du hast längere Methoden als Beispiel für eine sinnvolle Verwendung gebracht. Ich habe dazu nur gemeint, dass man anders besser löst. Sollte kein Angriff sein.

Das eine IDE es farblich kennzeichnet ob es sich um eine lokale oder eine Instanzvariable handelt ist echt kein Argument. Es soll auch Leute geben die benutzen noch den vi zum editieren....

Ich will wirklich niemanden seinen vi wegnehmen ;-) Die Leute haben sicher ihre Gründe dabei zu bleiben.
Aber, wenn mir mein Werkzeug einen bestimmten Komfort bietet, dann nutze ich ihn auch, um mir Aufwand zu ersparen.

Das Thema "this" ist allerdings nicht so wesentlich, dass man da lange drüber diskuttieren muss. in straff geführten Projekten gibt der technisch Verantwortliche so etwas einfach vor. In Eclipse kann dann noch die Option gewählt werden, dass bei Speichern alle unnötigen "this." automatisch entfernt werden. Danach braucht man sie da nie wieder Gedanken zu machen.

Eclipse bietet übrigens auch die Möglichkeit immer automatisch ein "this." einzufügen. Der Anteil der Programmierer, die es also haben wollen, scheint also zumindest ebenfalls relevant zu sein.

 

[Thallius]

Wenn man professionell Software entwickelt, dann versucht man eben auch Zeitfresser zu vermeiden.
Da stellt sich die Frage: Will man einen kompakten, klaren Code oder einen längeren mit Redundanzen? Wenn man seinen Code mit Selbstverständlichkeiten spickt, dann braucht man später auch entsprechend länger, diesen wieder zu verstehen.

Und genau da sind wir komplett gegensätzlicher Meinung. Ich weiß nicht wie oft Du schon fremden Code lesen mußtest, aber lass Dir gesagt sein, dass ist mein Tagesgeschäft. Und wenn ich mir nun eine Methode einer Klasse ansehen und das steht

    varaibles=anderervariable+nocheinevaraible

dann muss ich nachsehen wo diese Variablen deklariert sind. Im schlimmsten Fall sind es noch irgendwelche public static final oder so etwas grausames. Da suchst Du dir einen Wolf.

steht ein this davor, dann weiß ich sofort genau wo ich suchen muss.

Gruß

Claus

 

[Dompteur]

Ich weiß nicht wie oft Du schon fremden Code lesen mußtest, aber lass Dir gesagt sein, dass ist mein Tagesgeschäft.

Dann sind wir Leidensgenossen ;-)

Und wenn ich mir nun eine Methode einer Klasse ansehen und das steht

    varaibles=anderervariable+nocheinevaraible

dann muss ich nachsehen wo diese Variablen deklariert sind. Im schlimmsten Fall sind es noch irgendwelche public static final oder so etwas grausames. Da suchst Du dir einen Wolf.

steht ein this davor, dann weiß ich sofort genau wo ich suchen muss.

Wie gesagt, diese Information bekomme ich von der IDE geliefert. Auch der Aufruf der Stelle, wo die Variable definiert ist, ist nur einen Tastendruck entfernt.
Dabei bin ich nicht darauf angewiesen, dass der Entwickler dies berücksichtigt hat. Vor allem, wenn ich bestenden Code übernehmen muss, dann muss ich ihn nehmen, wie er ist.
Wobei ich generell sagen muss, dass eher Tools zur Analyse vertraue als nur halbherzig eingehaltenen Konventionen.

Aber wie ich schon im letzten Beitrag geschrieben habe: Ich weiß und akzeptiere, dass auch viele Entwickler das anders sehen.
Mir ist leider auch keine wissenschaftliche Untersuchung bekannt, ob das Auswirkungen auf die Produktivität hat.

 

[fanta5]

Wenn man seinen Code mit Selbstverständlichkeiten spickt, dann braucht man später auch entsprechend länger, diesen wieder zu verstehen.

Nein, das sehe ich komplett anders. Auch Kommentare, Blockklammern usw. kann man als für den Code "itself" als unnötigen Balast ansehen. Letztlich könnte man sogar Zeilenumbrüche als solchen ansehen.

Mir selber geht es oft so, daß ich (selbst meinen eigenen Code) nach Jahren deutlich besser verstehe, wenn ich recht großzügig mit all diesen "selbstverständlichkeiten" umgegangen bin.

f5

 

[Dompteur]

Ein, zwei Sätze vor dem zitierten Satz schrieb ich :

Das Beispiel mit dem vorangestellten "this." ist ja nur eines der Beispiele, die Code unnötig aufblasen. Andere Beispiele sind unnötige Klammern, nichtsagende Kommentare, usw.

Ich vertrete natürlich nicht die Ansicht, dass alle Kommentare, Blockklammern... unnötiger Balast sind.
Ich greif einmal Kommentare raus. Hier stelle ich mir immer zumindest 2 Fragen:

• Kann ich den Kommentar löschen, wenn ich meine Variablen/Methoden besser benenne ?
• Kann ich den Kommentar löschen, weil es nur eine Übersetzung des Java-Codes ist ? Ein Programmierer versteht den Java-Code doch ohnehin.

Was man beim Schreiben von Code und Kommentaren oft vergisst, ich dass der Code später geändert wird. Aber wie oft passiert es, dass man vergisst auch den Kommentar anzupassen.

Oder unnötige Klammern. Jeder weiss doch, dass Punkt vor Strichrechnung kommt.
Macht so etwas Sinn ?

umfang = ( 2 * laenge ) + ( 2 * breite );

Es ist zweifelsfrei richtig. Vielleicht hilft es einen Java-Anfänger sogar. Als professioneller Entwickler muss ich von meinen Kollegen aber erwarten, dass sie die Operatoren-Prioritäten auch ohne Klammern richtig verstehen.

Diese Beispiele sollten verdeutlichen, was ich als unnötigen Balast verstehe - auch wenn das etwas vom ursprünglichen Theme abweicht.

 

[Natac]

Können wir uns darauf einigen, dass die Verwendung von "this" etwas ist, worauf man sich verständigen muss? Ich denke es ist wichtig, dass man damit einheitlich umgeht. Also immer weglassen (wo möglich) oder immer hinschreiben. Was davon man nun macht muss man mit den Leuten absprechen mit denen man zusammenarbeitet (Kollegen, Dozent, etc...). Wirklich schlimm wird es nur, wenn man beides mischt und der Code damit wirklich unleserlich wird.

Ich persönlich lasse die IDE das "this" für mich anhängen (genau wie Klammern setzen, etc...), damit es über all steht, weil ich es nicht leiden kann, wenns manchmal dasteht und machmal nicht. Das kostet mich keine Zeit und sieht später trotzdem einheitlich aus. Aber das ist nur mein persönlicher Geschmack.

 

[JavaProfi]

Liebe Leute,

diese Diskussion um das Schlüsselwort "this" geht am Thema aber sowas von vorbei.
"this" verweist auf das aktuelle Objekt, also die aktuelle Instanz einer Klasse.

Das Schlüsselwort wurde eingeführt, da es in bestimmten Konstellationen zu Problemen bei der Referenzierung auf Variablen kommen kann.

Bei dem nachfolgenden Code würde es ohne die Verwendung von "this" sowohl bei der "Konstruktormethode" als auch bei beiden "setter"-Methoden zu einem falschen Verhalten kommen.
Das liegt daran, dass Instanzvariablen auch in den Methoden referenzierbar sind. Es gilt hier das Kaskadenmodell.

public class Point {
   private int x = 0;
   private int y = 0;

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

   public setX( int x) {
      this.x = x;
   }

   public setY( int y) {
      this.y = y;
   }
}

Übergebene primitive Parameter werden zu lokalen Variablen der aufgerufenen Methode.
Somit würde die Abwandlung des Codes (wie nachstehend) nicht die Instanzvariablen befüllen sondern lediglich die lokalen Variablen mit sich selbst überschreiben.

public class Point {
   private int x = 0;
   private int y = 0;

   public Point(int x, int y) {
      x = x;
      y = y;
   }

   public setX( int x) {
      x = x;
   }

   public setY( int y) {
      y = y;
   }
}

Und das ist schon der ganze Sinn und Zweck des Schlüsselwortes "this", nicht mehr, nicht weniger.
Die Verwendung von "this" wird obsolet, wenn der Quellcode aufgrund der sich gegenseitig ausschließenden Wahl der Variablenbezeichner eine solche Konfliktsituation nicht entstehen lässt.


Gruß
JP

 

[fanta5]

Lieber Java Profi,

ich glaube, was Du hier beschreibst, ist selber obsolet.

Jedem hier im Thread ist sonnenklar, was Du oben beschreibst. Genau deshalb diskutieren wir, ob es dennoch sinnvoll ist, das (eigentlich unnötige) this zu notieren. Ein nötig zu notierendes this stand eh nie zur Debatte.

f5

 

[JavaProfi]

Lieber fanta5,

Danke für den Hinweis.
Nur kann ich dann die Diskussion um so weniger verstehen.
Aber das muss ich dann wohl auch nicht.

Gruß
JP