saubere Variablendeklaration

[Fralle]

sicher gibt's schon einige Post's zu diesem Thema, trotzdem hab' ich noch ein paar Fragen dazu (auch weil in der Hilfe von Flash 8 in den Codebeispielen die Deklaration jetzt ein bisschen anders aussieht als bisher)

Im Grunde kann man unterscheiden zwischen 3 Arten:

meineVar = 0;
var meineVar = 0;
var meineVar:Number = 0; 

der Unterschied zwischen 1 und 2 ist mir eigentlich klar: lokal und global
Aber: ist es auch ein Unterschied wenn die Deklaration auf der Hauptzeitleiste (also _root.) stattfindet? Dann ist doch sowieso beides global, oder nicht?
dann:
Wenn ich in einer Funktion eine Schleife habe:

for (var i = 0; i < 10; i++)  {...} 

und dann danach in der gleichen Funktion nochmal eine Schleife vorkommt:

for (var i = 0; i < 10; i++)  {...} 

dann existiert die Variable "i" doch schon. Macht es da dann einen Unterschied, ob man den Deklarationsvorsatz "var" benutzt? Wie sollte man es richtigerweise machen?

darüber hinaus taucht nun in der Hilfe immer wieder diese Schreibweise auf:

for (var i:Number = 0; i < 10; i++)  {...} 

Wie "wichtig" ist dieses Number? Wie "schlimm" ist es, wenn man's weglässt? (p.s.: Kenne den Unterschied zwischen Number und String...)

Ich wär' doch so gern ein "sauberer" Programmierer!!
...muss aber doch immer wieder feststellen, daß ich nur 'ne Drecksau bin...

[André Michelle]

Sauber wäre dann keine Schleife im _root

Wenn du deine Schleifenvariable in einer Funktion definierst, dann ist sie auch lokal und nach Ablauf der Funktion in der GarbageCollection.

function init(): Void
{
	for( var i: Number = 0 ; i < 1 ; i++ )
	{
		trace( i );
	}
}

init();

trace( i );

[Janoscharlipp]

wobei ich dann mehr auf

PHP-Code:

var i : Number;

for (i = 0; i < 10; i++) {
    trace(i);
} 


stehe, da die Variablendeklaration eigentlich nicht ins for gehört.

Wichtig auch, dass du eine Variable nicht mehrfach deklarierst (wie es Macromedia so gerne macht), da dies dann im Mtasc nicht mehr funktioniert.

[Fralle]

Zitat von Janoscharlipp

Wichtig auch, dass du eine Variable nicht mehrfach deklarierst (wie es Macromedia so gerne macht), da dies dann im Mtasc nicht mehr funktioniert.

das meine ich ja! wieso aber macht MM das so und gibt diese Codebeispiele in der Hilfe?

[VdSnorri]

mal meine Bescheidene Meinung dazu:

i = 0 

ist old dirty stuff

var i = 0 

ist nicht global sonder lokal

_global.i = 0 

dies wäre global

var i:Number = 0 

ist mit Typisierung und geht nur in Zusammenhang mit

var 

Die Typisierung erlaubt Flash eine Kontrolle bei der Übergabe von Parametern und bei der Verarbeitung, daher sehr nützlich. Weiterhin wird dir beim Punkt Operator stehts die zum Typ gehörenden Funktionen angezeigt. Wiederum sehr nützlich.

for( i:Number = 0; i < 10; i++ ) { ... } 

ist meiner Ansicht nach ebenso sinnvoll, da i als Laufvariable nur in der For-Schleife Verwendung findet, weshalb sollte man sie daher ausserhalb deklarieren, das bringt nur Verwirrung mit sich.

for( i:Number = 0; i < 10; i++ ) { 
    for( i:Number = 0; i < 10; i++ ) { 
       ... 
    }
} 

Ein solches Konstrukt ist ein einziger Fehler, wie gesagt i Doppelt definiert ... sollte unbedingt verhindert werden.

[launcher]

Habe gerade bei meiner Suche nach einem Variablen-Deklarations-Problem im Forum dieses Thema gefunden. Ich liebte ja bisher diesen Weg, weil er schnell und unkompliziert ist:

fade_speed=4

Aber man soll ja Neuerungen gegenüber offen sein und deshalb habe ich mich mal mit der neuen empfohlenene Deklaration beschäftigt:

var fade_speed:Number = 4;

Von mir aus, dachte ich, gibt zwar keine schöne ESC-Tastenkombi und man muss Number immer ausschreiben aber was solls, wenn es sauberer (und angeblich schneller) ist ... okay.

Mit entsetzen musste ich feststellen, dass trotz meiner sauberen Deklaration (fade_speed ist eine Zahl) folgender Code nicht funktioniert, wenn fade_speed über ein Eingabefeld auf der Bühne geändert wird!

_root.mc._alpha += _root.fade_speed;

Was ist das denn fürn Mist? Da bleibe ich doch lieber bei meiner alten Methode, weniger Schreibarbeit und man muss nicht ne 1/2 Stunde Fehler suchen.

Funktionieren tuts übrigens nur so:

_root.mc._alpha += parseInt(_root.fade_speed);

[André Michelle]

@launcher: In welcher (Flash-) Version hast du das getestet ? Kann doch eigentlich gar nicht sein.

[launcher]

Hallo André,

Flash 8, veröffentlich für F8 AS2.

Ist verrückt, oder?

-------------------------------------

Hier noch ein Beispiel:

var a:Number = 5;
var b:Number = 2;
var c:Number = 7;
this.onEnterFrame = function() {
	c = a+b;
};

Ändert man in einem Eingabefeld auf der Bühne a in 4 - steht im dyn. textfeld c: na, wer weiß es?, richtig: 42

[André Michelle]

Ach so: Eingabefeld. Das ist richtig, weil immer Type String.

Also die Typen werden nur während des Kompilierens hinzugezogen und eben eventuelle Fehlermeldungen generiert. Während der Laufzeit werden keine Typen irgentwohin gebogen. Daher ist dein Fall auch etwas unschön, denn Eingaben in ein Textfeld sind immer Strings (per default). Das es früher ging ist aber aus meiner Sicht eher zu bemängeln, als das es jetzt nicht mehr geht. Es fehlt allerdings der CompilerError. In AS3 ist das alles viel besser gelöst.

Richtig wäre dann folgende Vorgegehensweise über beispielsweise ein UpdateEvent.

var value: Number = 0;

inputField.onChanged = function(): Void
{
	value = parseFloat( this.text );
}

Ach so, dass vorbeugende Massnahmen mehr Tipparbeit mit sich bringen ist klar :)

[launcher]

Hallo Ándre,

wenn das zur Laufzeit überhaupt nicht beachtet wird kann man sich das doch schenken, oder? Welche Vorteile (außer sauberer Code : ) hat das ganze denn sonst?

Gruß und Dank

Launcher

[Viktor M.]

Zitat von Fralle

Wie "wichtig" ist dieses Number? Wie "schlimm" ist es, wenn man's weglässt? (p.s.: Kenne den Unterschied zwischen Number und String...)

Zum einen ist das echt saubere Programmierung und zum anderen kommt man bei anderen Programmiersprachen wie C, Delphi oder Java gar nicht herum seine Variablen auch mit dem Typ zu versehen, den sie haben sollen.
Zudem schafft es transparenteren Code auch für andere, die sofort sehen welche Werte die Variable aufnehmen kann (wie z.B. eigene Datentypen wie structs o.ä.)

Uns wurde das während des Studiums schon so eingehämmert, dass ich gar micht gar nicht mehr traue eine Variable ohne Typ zu deklarieren ;-)

[André Michelle]

Das hat echte Vorteile, wenn man stipide alles typisiert, nicht nur einfache Typen wie Strings, Number, etc.

Zum ersten minimiert es duzende von Schreibfehlern, die man einfach macht und man reduziert sein Denken auf die Vorgehensweise des Rechners, was für komplexere Projekte unbedingt nötig ist.

Richtig spannend wird es dann mit AS3, weil dort Typisierung zudem noch einen Performancegewinn mit sich bringt. Also, untypisierte Variablen müssen vom Interpreter in Echtzeit ausgewertet werden. Mit ein Grund warum Actionscript 2- so langsam ist. Letztendlich braucht die unterste Ebene im Rechner immer Typen, um überhaupt etwas interpretieren zu können. Was gehört wohin und was kann ich damit anfangen.

Für mich war die konsequente Umsetzung von Typen erst der Begin, sicherer zu programmieren.

[launcher]

okay, ich nehms mir zu Herzen und warte gespannt auf den Performace-Gewinn in AS3

[André Michelle]

warte gespannt auf den Performace-Gewinn in AS3

Leg gleich los

[Fralle]

Wie sieht's denn aus mit Variablen, die den Typ wechseln?

Also, ich hab' z.B. eine Art Countdown in einer Andwendung. Da ist also ein Textfeld welches mir _root.countdownVAR anzeigt. Ganz klar ist das während des Countdowns eine Number. Damit aber das Textfeld nach dem Countdown leer ist hab' ich im Code folgendes:

_root.countdownVAR = ""; 

Da wird also die Number zum String...

Soll ich jetzt das Textfeld extra in einen MC packen und mit _visible arbeiten, oder gibt's noch andere Möglichkeiten?
Oder sollte man grundsätzlich keine Typen-Wechsel-Variablen (...so eine Schlmpe, die Variable!! ) benutzen?
Oder soll ich für den beschriebenen Fall eine zweite Countdown-Var deklarieren, die dann immer

countdownSTR = String(_root.countdownVAR); 

ist?