10.4 : Warum Inline-Variablen?

[Uwe Raabe]

Zitat von p80286:

Das ist doch die Argumentation der ewiggestrigen,

das sollte es gar nicht sein!

Ich wollte damit nur hervorheben, daß das für alle neuen Features gilt. Natürlich geht es auch ohne - wie hätten wir sonst auch arbeiten können. Das wertet ein neues Feature aber nicht ab.

Eventuell muss man sich nur erst daran gewöhnen. Manchmal geht das schneller, manchmal auch nicht.

[MyRealName]

Zitat von p80286:

Zitat von Uwe Raabe:

Zitat von Papaschlumpf73:

Ich kann auch gut ohne...

Konnten doch bisher alle, oder?

Das ist doch die Argumentation der ewiggestrigen, die sich jeder Neuerung sperren und die Flexibilität mit Chaos verwechseln. So bremst man den Fortschritt aus.

Gruß
K-H

Ich hatte es schonmal erwähnt, glaube ich, möchte aber hier im Thread nochmal ausdrücklich drauf hinweisen :

Als 10.3 rauskam habe ich ein Refactoring eines alten Services gemacht, der mit der Zeit aus dem Ruder lief. Das wollte ich dann auch gleich zusammen mit TMS Aurelius und einer neuen Modul-Factory, die ich mir überlegt hatte, machen. Da wollte ich natürlich auch gleich Inline Variablen ausprobieren. Erste Versuche sahen gut aus.
Aber als dann alles so halbwegs zusammengebaut war, gab es seltsame Effekte, Schutzverletzungen, die da nicht sein sollten. Ich habe Tage gesucht. Irgendwann habe ich in einem der Module, wo ich ständig Fehler hatte, dann doch alle Inline Variablen rausgeworfen. Siehe da, es funcktionierte, wie es sollte. Nachdem ich alle Inlines im ganzen Projekt rausgeworfen habe, traten keine Fehler mehr auf.

Vielleicht ist es ja besser seitdem, aber ich nutze dieses Feature mit Vorsicht.

[Harry Stahl]

Zitat von jaenicke:

Inline Variablen sind so ähnlich wie with:
Erleichtert das Schreiben von Code, verringert die Lesbarkeit und Wartbarkeit aber deutlich.

Immerhin hat es weniger negative Auswirkungen als with. Wenn aber der Rückgabewert einer Methode sich ändert, ändert sich ohne Typangabe auch plötzlich der Typ. Und dann kommt an ganz anderer Stelle ein Fehler.

Ich finde außerdem, dass es den Quelltext schlechter lesbar macht.

Aber wie so vieles (Quelltextformatierung, ...) ist es eben Geschmackssache. Ich persönlich werde das Feature sicher sehr spärlich verwenden... außer bei Schleifen, wo es durchaus praktisch ist, dass die Variable danach nicht mehr verfügbar ist. Das muss jeder für sich selbst entscheiden.

Warum findest Du, dass es den Code schlechter lesbar macht? Ich habe da eher die gegenteilige Erfahrung gemacht.

Wenn ich mir eine Funktion ansehe, die ein anderer geschrieben hat (oder ich selber vor längerer Zeit) und sich da im Var-Bereich 5-10 Variablen-Deklarationen tummeln, weiß ich dann noch, wenn ich mir 50 Zeilen code durchgelesen habe, welchen Typ eine Variable hat, wenn sie zum ersten mal zum Einsatz kommt?

Per inline var kommt der Typ der Variable ins Spiel, wenn ich an der Stelle bin, wo die Variable gebraucht wird. Wenn die Variablenbezeichnung (z.B. sInitName) schon selbst den Typ erklärt, reicht ein


var sInitName := 'MusterMann';
Hab ich was komplexeres oder mehrdeutiges, dann nehme ich da noch den Typ hinzu:

Delphi-Quellcode:

var MyStdPowerSrc : TBattery := GetPower (PowerSrc);

// statt: MyStdPowerSrc :=  GetPower (PowerSrc);

Ich weiß dann genau an der Stelle wo die Variable zum Einsatz kommt, dass MyStdPowerSrc eben von der Klasse TBattery ist und muss nicht 40 Zeilen weiter oben nachsehen, ob MyStdPowerSrc nun TBattery oder TSolarPanel war, das noch an anderer Stelle in der Funktion in einem else-Zweig zum Einsatz kommt...

Aber so richtig hast Du ja noch gar nicht erklärt, warum Du der Meinung bist, dass die Lesbarkeit schlechter ist ...

[himitsu]

Zitat:

weiß ich dann noch, wenn ich mir 50 Zeilen code durchgelesen habe, welchen Typ eine Variable hat

Es gibt ja viele Leute, die uns versuchen beizugringen, dass Funktionen immer ganz Kurz sein müssen, und schon gibt es das Problem nicht.

Alternativ arbeitest du besser mit einem 21:9 Monitor im Hochformat und bekommst dann auch wieder die Funktion in einem Blick auf den Bildschirm.
oder besser gleich 16:3 https://www.itboost.de//eshop.php?ac...r_aid=10949605

[MyRealName]

Zitat von himitsu:

Zitat:

weiß ich dann noch, wenn ich mir 50 Zeilen code durchgelesen habe, welchen Typ eine Variable hat

Es gibt ja viele Leute, die uns versuchen beizugringen, dass Funktionen immer ganz Kurz sein müssen, und schon gibt es das Problem nicht.

Alternativ arbeitest du besser mit einem 21:9 Monitor im Hochformat und bekommst dann auch wieder die Funktion in einem Blick auf den Bildschirm.
oder besser gleich 16:3 https://www.itboost.de//eshop.php?ac...r_aid=10949605

Ich nutze einen 32:9 bei 5120 x 1440, aber der geht nicht hochkant, weil er curved ist. Ist aber trotzdem ein sehr gutes Arbeiten drauf und noch besseres Spielen.

[Rollo62]

Wo ich das gerade sehe, wer hat mit Inline schon was getestet ?

Kann die Inline-Variable in einem Scope auch umdeklariert werden, vielleicht so ?
Ich würde erwarten das es geht, aber die Erfahrung lehrt mich ...

Delphi-Quellcode:

var MyStdPowerSrc := TBattery.Create;
MyStdPowerSrc.Free

...

var MyStdPowerSrc := TSolarPanel.Create;  //wird hier der Typ TBattery gg. TSolarPanel getauscht ?
MyStdPowerSrc.Free

Ich vermute mal das es nicht geht, weil dann verschachtelte Prozeduren damit nicht klarkommen.

[Der schöne Günther]

Ein schönes praktisches Beispiel wie man sich selbst ins Knie schießen kann hat Microsoft kürzlich erzählt. Ein uralter Bug in FAT32 lag im Endeffekt auch an einer unglücklich platzierten Deklaration einer Variable:

(Runterscrollen zu "Use-After-Free in FAT32")
https://msrc-blog.microsoft.com/2020...ry-on-windows/

Zitat:

The code was something along the lines of this:

Code:

for(int i = 0; i < size; i++)
{
      int tmp;
      DoStuff(&tmp, i);
}

This code was running in a loop. A variable was declared inside of the loop. On the first iteration of the loop, the function DoStuff would initialize the variable “tmp” that it is passed the address to. On every additional iteration of the loop, the variable “tmp” was used as an in/out parameter. In other words, the variable would be read from and then updated.

The issue here is that the variable comes in scope at the beginning of each iteration of the loop and goes out of scope after each iteration of the loop. With InitAll enabled, this variable is zero initialized for each iteration of the loop. This is effectively a use-after-free. This code is depending on the value of “tmp” being preserved each iteration of the loop even though it goes out of scope at the end of each iteration.

[DasWolf]

Zitat von Harry Stahl:

Wenn ich mir eine Funktion ansehe, die ein anderer geschrieben hat (oder ich selber vor längerer Zeit) und sich da im Var-Bereich 5-10 Variablen-Deklarationen tummeln, weiß ich dann noch, wenn ich mir 50 Zeilen code durchgelesen habe, welchen Typ eine Variable hat, wenn sie zum ersten mal zum Einsatz kommt?

Mauszeiger drüber, fertig!

[sakura]

Zitat von DasWolf:

Mauszeiger drüber, fertig!

Kostet zu viel Zeit

Im Ernst, Inline-Variablen haben, wie alles, Vor- und Nachteile. Größter Nachteil ist sicherlich, dass der Code nicht rückwärts kompatibel ist. Früher empfand ich beim Gedanken daran, die könnten in Delphi ankommen (übrigens schon in Delphi 103 ) einen riesigen Graus. Seit sie da sind, empfinde ich diese als sehr angenehm. Gerade in Schleifen kann man deren Fokus lokal begrenzen und diese nicht aus Versehen außerhalb nutzen. Wenn man sich später entscheidet eine gewachsene Methode zu refaktorieren, dann wird dieses auch deutlich angenehmer, da man weniger hin- und her springen muss. Mit Einführung der inline-Deklaration habe ich meine Coding-Stil ein wenig umgestellt und angepasst.

Variablen im VAR-Bereich gebe ich die Garantie, dass diese überall in der Methode; abgesehen von den ersten Zeilen zur Initialisierung derer; eine sinnvollen Wert haben. Ergo, wenn diese dort aufgeführt sind, kann ich innerhalb der Methode jederzeit bedenkenlos darauf zu greifen. Wenn diese erst später sinnvoll belegt werden können, dann deklariere ich diese später.

Jetzt gibt es das Gegenargument, dass ja der Compiler Warnungen auswirft. Und ja, ich strebe grundsätzlich nach einer 0 bei Warnungen und bei Hinweisen, aber die übersieht man doch mal schnell und man verliert wieder wertvolle Stunden beim Suchen nach Fehlern...

Inline-Variablen sind ein neues, stilistisches Mittel, von daher, denke ich, sollte man entspannt sein, wenn man diesen begegnet und der Code nicht in älteren Delphi-Compilern funktionieren muss. Keiner wird gezwungen diese einzusetzen, aber man sollte auch keinen dafür verurteilen.

ABER, ja auch das alte with ist ein stilistisches Mittel, aber es ist auch weithin bekannt, dass es schnell zu Fehlern und Problemen führt. Daher darf man hier durchaus auf die Barrikaden gehen, wenn es ein Kollege nutzt.

Und noch ein weiterer sehr guter Platz für Inline-Variablen.

Code:

{$IFDEF DEBUG} .... 
wer hier etwas berechnen muss, musste bisher auch immer ein nervendes 
IFDEF im VAR Block haben, was nie gut aussah - oder mit Hinweisen des 
Compilers leben. Hier ein, zwei Inline-Variablen sind sehr angenehm 
für die allgemeine Lesbarkeit des Codes ;-)
{$ENDIF}

My 2 cents...

......

[Harry Stahl]

Zitat von DasWolf:

Zitat von Harry Stahl:

Wenn ich mir eine Funktion ansehe, die ein anderer geschrieben hat (oder ich selber vor längerer Zeit) und sich da im Var-Bereich 5-10 Variablen-Deklarationen tummeln, weiß ich dann noch, wenn ich mir 50 Zeilen code durchgelesen habe, welchen Typ eine Variable hat, wenn sie zum ersten mal zum Einsatz kommt?

Mauszeiger drüber, fertig!

Man sieht sich Source-Code ja nicht nur in Delphi an, sondern auch Online im Webbrowser oder in einem anderen Programm, da geht das mit dem Mauszeiger drüber leider nicht...