10.4 : Warum Inline-Variablen?

[himitsu]

Moin,

ich weiß ja dass Viele es sich wünschten und es in anderen viel cooleren Sprachen sowas schon lange gibt,
aber wieso musste man sowas auch unbedingt ins Pascal einbauen?

Man soll doch Funktionen eh so klein wie möglich machen und alles schön viel aufteilen,
da gibt es doch eigentlich keinen Grund seine Variablen nicht übersichtlich an den drei alt bekannten Stellen zu sammeln. Hier also Lokal vor's BEGIN.



OK, ich musste erstmal ausprobieren, aber es geht wirklich und es ist für mich aktuell die einzige Stelle, wo es schon ganz nett sein könnte.

Delphi-Quellcode:

for var I := 0 to 3 do 
  ...

// oder
for var i in [0..3] do  // mit einem Enum sieht es noch besser aus
  ...

Aber die andere Stelle, wo es von der neuen Syntax her viel Sinn ergeben würde, da darf man es nicht machen, um diese Variable endlich mal richtig zu kennzeichnen. :shock:

Delphi-Quellcode:

try

except
  on var E: Exception do
    ...
end;

und sowas geht auch nicht. :cry:

Delphi-Quellcode:

procedure TForm2.FormCreate(Sender: TObject);
begin
  var i: Integer = 2;  // EDIT: das hier geht, wenn man := verwendet, aber es weicht doch zu sehr von der Konstantensyntax ab
  if var x := i + 3 then
    if x = 5 then juhuuu;
end;

Variablen im IF umzuschreiben ist doch das Beste, was es jemals gab.
Ich kann mich noch gut an den Spaß erinnern, wo ich im PHP statt einen == nur ein = machte und dann Stunden freudig juchzend gesucht hatte, warum sich der Wert einer Variable ändert.

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

[himitsu]

Ohhhhhhh, stimmt ja, das blöde WITH, ganz vergessen. :oops: :thumb:
Jetzt wo du es sagst, dort hatte ich mir schonmal sowas wie beim on-do gewünscht (Inline-Variable :wall:).
z.B.

Delphi-Quellcode:

with e := ... do ...

statt

Delphi-Quellcode:

with xxx do ...

und jetzt

Delphi-Quellcode:

begin var E := xxx; .... end;

, also eigentlich das Gleiche/Selbe, nur mit 'ner anderen Syntax.

OK, also Ersatz für das WITH ist dieses VAR doch wirklich mal ein besserer Ersatz,
aber bei einer kurzen Funktion würde doch nichts dagegen sprechen die Variable 3 Zeilen höher zu definieren.

[Papaschlumpf73]

Ich kann auch gut ohne...

[Harry Stahl]

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

https://www.delphipraxis.net/1465551-post57.html

Wer es noch ein wenig ausführlicher und mit weiteren Argumenten nachlesen möchte:

https://landgraf.dev/en/5-reasons-to...les-in-delphi/
https://www.ideasawakened.com/post/n...bles-in-delphi
https://blog.grijjy.com/2018/11/02/i...e-performance/

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1465567)

OK, also Ersatz für das WITH ist dieses VAR doch wirklich mal ein schöner Ersatz,
aber bei einer kurzen Funktion würde doch nichts dagegen sprechen die Variable 3 Zeilen höher zu definieren.

Dann aber mit begin..end drum herum...

Delphi-Quellcode:

procedure TForm71.FormCreate(Sender: TObject);
begin
  begin
    var a := 42;
    ShowMessage(IntToStr(a));
  end;
  a := 33; // hier gibt es die Variable nicht mehr --> Fehler
end;

Auf die Weise kann man Interfaces z.B. wieder aus dem Scope laufen lassen.

Es gibt schon durchaus Stellen, an denen es Sinn macht so etwas zu verwenden. Darum sage ich ja auch, dass ich persönlich es nicht möchte. Aber ich verstehe durchaus, wenn das jemand anders sieht. ;-)

Zitat:

Zitat von Harry Stahl (Beitrag 1465570)

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

https://www.delphipraxis.net/1465551-post57.html

Type inference ist der Teil daran, der mir weniger gefällt, so praktisch es auch sein mag. Aber der Punkt, dass man genau den Typ angibt, den man meint, der Compiler es prüft usw. war immer eine der wichtigsten Stärken von Pascal / Delphi. Das wird damit aufgeweicht.

[Uwe Raabe]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1465568)

Ich kann auch gut ohne...

Konnten doch bisher alle, oder?

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1465573)

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1465568)

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

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1465578)

Das ist doch die Argumentation der ewiggestrigen,

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

[p80286]

Du hast mich zu ernst genommen. Ist halt kein Killerfeature.

Gruß
K-H

[Harry Stahl]

Zitat:

Zitat von Harry Stahl (Beitrag 1465570)

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

Zitat:

Zitat von jaenicke (Beitrag 1465571)

https://www.delphipraxis.net/1465551-post57.html

Type inference ist der Teil daran, der mir weniger gefällt, so praktisch es auch sein mag. Aber der Punkt, dass man genau den Typ angibt, den man meint, der Compiler es prüft usw. war immer eine der wichtigsten Stärken von Pascal / Delphi. Das wird damit aufgeweicht.

Erfreulicherweise läßt Delphi Dir die Wahl.

Statt

Delphi-Quellcode:

var files := System.ioutils.TDirectory.GetFiles (edDir.Text, '*.*');

kanst Du auch

Delphi-Quellcode:

var files : TStringDynArray := System.ioutils.TDirectory.GetFiles (edDir.Text, '*.*');

schreiben...

[Harry Stahl]

Zitat:

Zitat von jaenicke (Beitrag 1465566)

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

Delphi-Quellcode:

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

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 :stupid: https://www.itboost.de//eshop.php?ac...r_aid=10949605

[MyRealName]

Zitat:

Zitat von p80286 (Beitrag 1465578)

Zitat:

Zitat von Uwe Raabe (Beitrag 1465573)

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1465568)

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

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.

[MyRealName]

Zitat:

Zitat von himitsu (Beitrag 1465604)

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

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

[Stevie]

Type Inference: Friend or Foe

[freimatz]

Zitat:

Zitat von MyRealName (Beitrag 1465614)

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.

Selber schuld: Bei Software benutzt man NIE die erste Version (eines neuen Features) - erst recht nicht bei Delphi. :wink:

[Harry Stahl]

Zitat:

Zitat von Der schöne Günther (Beitrag 1465619)

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.

Das ist aber Fehler, der auch auch ohne Inline-Var recht ähnlich möglich wäre:

Delphi-Quellcode:

var
  tmp: Integer;
begin
  for L := 1 to 10 do begin
    // tmp := 0;  <-- Oder so was
    inc (tmp);
    DoStuff (L, tmp);
  end;

Delphi würde Dir in dem oben beschriebenen C-Beispiel mit INLINE-Var eine Warnung ausgeben, dass tmp möglicherweise nicht initialisiert sei (so was wie ein "InitAll" gibts unter Delphi nicht).

Im meinem Fehler-Beispiel erhältst Du auch eine Warnung wegen der fehlenden Initialisierung (es sei denn Du initialisierst in der Schleife, dann nicht).

Aber ich sag mal: Jeder so wie er meint. Ich freue mich jedenfalls die zusätzliche Option zu haben und werde Sie auch nutzen, die Artikel in den Links, die ich oben genannt habe, führen ja auch sehr gute Gründe für eine Verwendung auf.

Wer es nicht mag, lässt es einfach...

[DasWolf]

Zitat:

Zitat von Harry Stahl (Beitrag 1465599)

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:

Zitat von DasWolf (Beitrag 1465679)

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

...:cat:...

[Harry Stahl]

Zitat:

Zitat von DasWolf (Beitrag 1465679)

Zitat:

Zitat von Harry Stahl (Beitrag 1465599)

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

[jaenicke]

Zitat:

Zitat von Harry Stahl (Beitrag 1465692)

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

Ein weiteres Argument gegen type inference. ;-)

Allerdings dürfte der Anteil des Ansehens größerer Codeteile außerhalb von Delphi recht gering sein.

[Uwe Raabe]

Zitat:

Zitat von jaenicke (Beitrag 1465693)

Allerdings dürfte der Anteil des Ansehens größerer Codeteile außerhalb von Delphi recht gering sein.

Auch schon wegen der fehlenden Navigationsmöglichkeit - sowohl in der Unit als auch außerhalb.

[Harry Stahl]

Zitat:

Zitat von Uwe Raabe (Beitrag 1465696)

Zitat:

Zitat von jaenicke (Beitrag 1465693)

Allerdings dürfte der Anteil des Ansehens größerer Codeteile außerhalb von Delphi recht gering sein.

Auch schon wegen der fehlenden Navigationsmöglichkeit - sowohl in der Unit als auch außerhalb.

Na gut, evtl. ist das bei mir ein Sonderfall, ich sehe mir viel Source-Code in meinem Pascal-Editor an. Der kann zwar auch zu den meisten Variablen-Deklarationen hinspringen, aber "Maus drüber" kann er nicht. Dazu müsste das Programm wie ein Compiler funktionieren, mit entsprechendem Programmaufwand und Speicherverbrauch.

Mal abgesehen davon - ich habe es schon mal erwähnt - jeder wie er will.

Aber: Die mal als Argument genannte Rückwärtskompatibilität? Wenn man auch nur eine sprachliche Neuerung von jeder neuen Delphi-Version nutzt (und da gibt es ja seit den letzten Jahren dutzende) dann hat man schon eine ganze Latte von Problemen.

Deswegen auf all die tollen neuen Features verzichten (Generics, TDictionary, TMessageManger, Threading, Managed Records, Inline vars ,etc.), nur damit jeder code noch in einem alten Delphi Schätzchen läuft?

Für mich gilt da: --> Nö.

[sakura]

Zitat:

Zitat von Harry Stahl (Beitrag 1465700)

Aber: Die mal als Argument genannte Rückwärtskompatibilität? Wenn man auch nur eine sprachliche Neuerung von jeder neuen Delphi-Version nutzt (und da gibt es ja seit den letzten Jahren dutzende) dann hat man schon eine ganze Latte von Problemen.

Das ist klar, aber wenn man Bibliotheken anbietet die für den Markt sind, dann ist es durchaus ein Argument, wenn man ein paar mehr Versionen unterstützen mag ;-)

...:cat:...

[Harry Stahl]

Zitat:

Zitat von sakura (Beitrag 1465711)

Zitat:

Zitat von Harry Stahl (Beitrag 1465700)

Aber: Die mal als Argument genannte Rückwärtskompatibilität? Wenn man auch nur eine sprachliche Neuerung von jeder neuen Delphi-Version nutzt (und da gibt es ja seit den letzten Jahren dutzende) dann hat man schon eine ganze Latte von Problemen.

Das ist klar, aber wenn man Bibliotheken anbietet die für den Markt sind, dann ist es durchaus ein Argument, wenn man ein paar mehr Versionen unterstützen mag ;-)

...:cat:...

Da stimme ich Dir zu. Es zeigt also mal wieder, dass es eben auf den gegebenen Kontext ankommt... Bei mir spielt dieser Aspekt gar keine Rolle (jedenfalls derzeit)), bin also in dieser Hinsicht erfreulicherweise da nicht eingeschränkt.

Wobei man da aber auch anmerken muss, dass man bei allzu viel Selbstbeschränkung dann evtl. nicht alles rausholen kann, was einem neue Programmiertechnicken und Bibliotheken so bieten, sei es Zuverlässigkeit oder Geschwindigkeit oder generell die Breite potentieller Features...

[Stevie]

Warum sind Delphientwickler eigentlich so typenfixiert? Vermutlich weil sie es nicht anders kennen.
In einem Großteil der Software spielt es keine Rolle, welchen exakten Typen eine Variable hat, sofern der Variablenname deutlich ist (siehe auch der von mir zuvor verlinkte Vortrag).
Ja, ich weiß, es gibt immer diesen Fall, wo das wichtig ist - dann schreib den Typen halt dran.

Aber ob nun die Variable usernames eine TList<string>, IList<string>, TArray<string> oder TStringList ist, spielt keine Rolle, wenn man sie von einer Funktion entgegen nimmt und weiter gibt oder iteriert (ja, ich weiß, dass TArray<string> keine .Add oder andere Methoden hat) und ist für das Verstehen des umliegenden Codes vermutlich komplett irrelevant und somit "ceremony".

Zitat:

Zitat von sakura (Beitrag 1465711)

wenn man Bibliotheken anbietet die für den Markt sind, dann ist es durchaus ein Argument, wenn man ein paar mehr Versionen unterstützen mag ;-)

Ja, und trotzdem genieße ich es inzwischen, wenn ich beim Ausprobieren und Testen inline Variablen inklusive Typinferenz benutzen kann. :)

[Hobbycoder]

ich find's ne tolle Sache.
Wenn ich irgendwo in einer längeren Prozedur eine Variable tatsächlich nur einmal brauche, weil's nicht anders geht, dann finde ich das völlig okay und extrem praktisch.
Alle Anderen kommen da hin, wie sie hingehören.

Das macht meiner Meinung nach einen Code sogar noch lesbarer. In meinen weiß ich zumindest, wenn eine Var Inline deklariert ist, wird sie weiter unten im Code nicht mehr verwendet.

Frei nach dem Motto: Alles ist Gesund, wenn man es in Maßen genießt.

[Lemmy]

Zitat:

Zitat von Hobbycoder (Beitrag 1465748)

Das macht meiner Meinung nach einen Code sogar noch lesbarer. In meinen weiß ich zumindest, wenn eine Var Inline deklariert ist, wird sie weiter unten im Code nicht mehr verwendet.

völlig richtig! Denn: Kannst Du in einer längeren Prozedur eine Inline-Variable verwenden, dann liegt der Verdacht doch sehr nahe, dass dieser Codeteil in eine eigene Methode refactored werden kann.

[Hobbycoder]

Zitat:

Zitat von Lemmy (Beitrag 1465750)

Zitat:

Zitat von Hobbycoder (Beitrag 1465748)

Das macht meiner Meinung nach einen Code sogar noch lesbarer. In meinen weiß ich zumindest, wenn eine Var Inline deklariert ist, wird sie weiter unten im Code nicht mehr verwendet.

völlig richtig! Denn: Kannst Du in einer längeren Prozedur eine Inline-Variable verwenden, dann liegt der Verdacht doch sehr nahe, dass dieser Codeteil in eine eigene Methode refactored werden kann.

Kann...aber nicht muss.

Einen Nutzen, den ich mir aus der Möglichkeit Inline-Vars zu verwenden ziehe ist wenn ich mir rein zu Debuggingzwecken mal schnell einen Wert in einer Variable zu halten.

[Moombas]

Zitat:

Zitat von Hobbycoder (Beitrag 1465748)

Das macht meiner Meinung nach einen Code sogar noch lesbarer. In meinen weiß ich zumindest, wenn eine Var Inline deklariert ist, wird sie weiter unten im Code nicht mehr verwendet.

Warum benutzt du dann nicht einfach eine Konstante?
Dann kann sie weiter unten im Code gar nicht erst verändert werden!
Für mich kein Argument einer Inline-Deklaration

Ich sehe eigentlich nur einen Vorteil, bin aber nicht ganz so bewandert wie viele andere hier.
Man kann eine Variable festlegen und den "Initialwert" gleich mit festlegen und diesen auch sofort erkennen.

[Stevie]

Zitat:

Zitat von Moombas (Beitrag 1465762)

Warum benutzt du dann nicht einfach eine Konstante?
Dann kann sie weiter unten im Code gar nicht erst verändert werden!
Für mich kein Argument einer Inline-Deklaration

Es gibt eine kleinen aber feinen Unterschied zwischen einer Konstanten und einer read-only Variable

Schau mal, was mit den inline Variablen feines geht:

Delphi-Quellcode:

begin
  var i := 0;
  Readln(i);
  const s = i.ToString; // read only variable!
//  s := 'test'; // würde nicht kompilieren!
  Writeln(s);
  Readln;
end.

[Moombas]

Stimmt, da hast du recht, das es in diesem Fall gut und Sinnig ist.
Da man in so einem Fall natürlich die Konstante gar nicht vorher setzen kann, sondern das nur als Variable ginge.

Da ist mein Gedankengang Variable <> Konstante halt da gewesen und nicht dran gedacht das man hier ja von beidem redet: Inline-Variable (macht aus meiner Sicht selten Sinn) und Inline-Konstante (macht häufiger mal Sinn).

Aber das ist nur meine Meinung.

[OlafSt]

Es ist schon erstaunlich, das hunderttausende von C-, C++ -, und C#-Entwicklern seit Jahrzehnten (!) mit diesem Feature zurechtkommen und trotzdem guten Code schreiben können. Ich vermisse dieses Feature in Delphi schmerzlich und bin froh, das es nun Einzug hält.

[Heimlich]

Zitat:

Zitat von Moombas (Beitrag 1465762)

Ich sehe eigentlich nur einen Vorteil, bin aber nicht ganz so bewandert wie viele andere hier.
Man kann eine Variable festlegen und den "Initialwert" gleich mit festlegen und diesen auch sofort erkennen.

Na dann schau mal hier:

Delphi-Quellcode:

unit Unit1;

interface
  uses Unit2;
...
...

begin
  var IstEinText := GetIstEinText;
 ...
 ...
end;

Delphi-Quellcode:

unit Unit2;

interface

function GetIstEinText: string;

implementation

function GetIstEinText: string;
begin
  Result := 'Ja, das ist ein Text.';
end;

Wahrscheinlich denkt man erst, es ist ein Boolean, aber Pustekuchen.

Damit wäre Folgendes obsolet:

Zitat:

Zitat von Stevie (Beitrag 1465743)

In einem Großteil der Software spielt es keine Rolle, welchen exakten Typen eine Variable hat, sofern der Variablenname deutlich ist (siehe auch der von mir zuvor verlinkte Vortrag).

...weil Variablennamen nicht vorgeschrieben werden.


Also ist es kein Vorteil, sondern es könnte einen Vorteil sein, aber könnte ist nichts Halbes und nichts Ganzes.

[Moombas]

@Heimlich: Das Problem liegt aber in der Art der "Initialisierung" des Wertes.
Für mich ist die Initialisierung niemals mit einer Funktion verbunden aber evtl. bin ich da auch alleine mit.

[Heimlich]

Zitat:

Zitat von OlafSt (Beitrag 1465774)

Es ist schon erstaunlich, das hunderttausende von C-, C++ -, und C#-Entwicklern seit Jahrzehnten (!) mit diesem Feature zurechtkommen und trotzdem guten Code schreiben können. Ich vermisse dieses Feature in Delphi schmerzlich und bin froh, das es nun Einzug hält.

Du verwechselt da gerade was. Hunderttausende von C-, C++ -, und C#-Entwicklern schreiben seit Jahrzehnten funktionierenden Code, aber bestimmt keinen guten und schon gar keinen sauberen.
Deshalb hat folgender Satz von Niklaus Wirth immer noch Bestand:
"C++ is an insult to the human brain."
Das kann man auch bei C# sagen.

[DieDolly]

Zitat:

Zitat von jaenicke (Beitrag 1465571)

Zitat:

Zitat von himitsu (Beitrag 1465567)

OK, also Ersatz für das WITH ist dieses VAR doch wirklich mal ein schöner Ersatz,
aber bei einer kurzen Funktion würde doch nichts dagegen sprechen die Variable 3 Zeilen höher zu definieren.

Dann aber mit begin..end drum herum...

Delphi-Quellcode:

procedure TForm71.FormCreate(Sender: TObject);
begin
  begin
    var a := 42;
    ShowMessage(IntToStr(a));
  end;
  a := 33; // hier gibt es die Variable nicht mehr --> Fehler
end;

Auf die Weise kann man Interfaces z.B. wieder aus dem Scope laufen lassen.

Es gibt schon durchaus Stellen, an denen es Sinn macht so etwas zu verwenden. Darum sage ich ja auch, dass ich persönlich es nicht möchte. Aber ich verstehe durchaus, wenn das jemand anders sieht. ;-)

Zitat:

Zitat von Harry Stahl (Beitrag 1465570)

Ich habe zufälligerweise gerade etwas dazu in diesem Beitrag geschrieben:

https://www.delphipraxis.net/1465551-post57.html

Type inference ist der Teil daran, der mir weniger gefällt, so praktisch es auch sein mag. Aber der Punkt, dass man genau den Typ angibt, den man meint, der Compiler es prüft usw. war immer eine der wichtigsten Stärken von Pascal / Delphi. Das wird damit aufgeweicht.

Ist aber umständlich mit begin und end. Wenn dann doch besser mit let statt var, so wie es in JavaScript ist.