Bemerkenswertes in der Programmiersprache Dart
Wie in anderen Programmiersprachen auch, gibt es in Dart oft nicht nur eine Variante, wie man ein Problem lösen kann.
Ich schreibe diesen Post eigentlich auch, um mir diese Punkte wieder in Erinnerung zu rufen. Der Code ist, wie in allen Beispielen auf diesem Blog, getestet und mit der aktuellen Version von Dart lauffähig. Im Falle von Dart ist das 2.3.2 und von Flutter v1.5.4-hotfix.2.
Auch eine Funktion hat einen Typ
bool demofunktion(){ var meineVariable = true; return meineVariable; } void main() { print(demofunktion()); }
Im Code oben sehen wir eine Funktion die einen bool Wert retourniert. Durch die Schreibweise
bool demofunktion(){...} wissen wir beim lesen sofort was für einen Variablen Typ die Funktion zurückgibt. Sollten wir eine sehr große Funktion haben und der Variablen Typ den wir retournieren, stimmt nicht mit dem Typ überein, welchen wir deklariert haben, wird der Compiler uns eine Fehlermeldung anzeigen. Dart akzeptiert wenn man bei einer Funktion keinen Typ angibt. Der Code oben läuft auch problemlos wenn wir nur demofunktion(){...} schreiben. Die Folge ist aber, das Dart keine Kontrolle mehr über den retournierten Wert hat. So kann sich ein Fehler einschleichen der unter Umständen schwer zu finden ist.
Bauen wir die Fehlerquelle aus..
demofunktion(){
var meineVariable = true;
return meineVariable;
}
void main() {
var irgendetwas = demofunktion();
print(demofunktion());
print(irgendetwas);
}
Diesmal haben wir im Code oben zweimal den Variablen Typ var. Das gute und gleichzeitig problematische mit var ist: er kann alles enthalten !
Wir können ihm eine List oder auch ein Widget zuweisen, eine Zeichenkette oder eine map. Das ist natürlich bequem, aber eben auch gefährlich, da fehleranfällig.
Im Code oben haben wir dem Compiler sowohl die Kontrolle darüber entzogen was der Return Typ von demofunktion ist, als auch die Kontrolle darüber, was für einen Typen genau, wir in der Variablen irgendetwas erwarten.
Es ist deshalb ein guter Rat erstens auf die Verwendung von var, aber auch dynamic zu verzichten und zweitens eine Funktion immer mit einem Typen für die retournierte Variable aus zustatten.
Es mag Situationen geben, wo das nicht zielführend ist. Das dürfte aber sehr selten sein.
Robin Hood hat einen Pfeil oder kürzer ist besser ?
bool demofunktion(){ bool meineVariable=true; return meineVariable; } void main(){ print(demofunktion()); }
Wie ist Print(demofunktion()); zu lesen ?
Genau! Mit print können wir sowohl Zeichenketten als auch andere Objekte in die Konsole drucken.
Wir können, wenn wir denn unbedingt wollen, ein ganzes JSON File in die Konsole drucken.
In diesem Beispiel übergeben wir print demofunktion als Argument. Das heisst:
demofunktion(...) wird ausgeführt..und das Resultat ist das Argument für die print(...) Funktion
Dieses Prinzip, das das Resultat einer Funktion umgehend weiterverwendet wird ist in Dart und Flutter immer wieder zu finden. Jetzt können wir den Code oben, die main(...) Funktion um genau zu sein, noch ein wenig abändern:
void main() => print(demofunktion());
Das sieht jetzt sehr kompakt aus. Eigentlich ersetzt => die geschweiften Klammern {...} und die Zeilenumbrüche. Es macht den Quellcode also "besser" leserlich. Vom Inhalt her ist es aber gleichwertig mit der Variante weiter oben. Diese fat arrow notation, wie sie in der englisch sprachigen Dart Gemeinde genannt wird, ist ebenfalls häufig anzutreffen.
Dabei ist zu beachten das der Code rechts vom Pfeil eine singleExpression sein muss. Damit ist gemeint: demofunktion(...) hat 1 Resultat, dieses wird durch print(...) weiterverwendet und print ist 1 Anweisung. Deshalb auch die fehlenden {...}, man kann print(demofunktion()) als eine Anweisung betrachten. Nur für diese Situationen ist die => Variante zulässig.
Kommentare
Kommentar veröffentlichen