Delphi-Version: 10.4 Sydney
10.4 : Warum Inline-Variablen?
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:
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:
for var I := 0 to 3 do
... // oder for var i in [0..3] do // mit einem Enum sieht es noch besser aus ...
Delphi-Quellcode:
und sowas geht auch nicht. :cry:
try
except on var E: Exception do ... end;
Delphi-Quellcode:
Variablen im IF umzuschreiben ist doch das Beste, was es jemals gab.
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; 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. |
AW: 10.4 : Warum Inline-Variablen?
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. |
AW: 10.4 : Warum Inline-Variablen?
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:
statt
with e := ... do ...
Delphi-Quellcode:
und jetzt
with xxx do ...
Delphi-Quellcode:
, also eigentlich das Gleiche/Selbe, nur mit 'ner anderen Syntax.
begin var E := xxx; .... end;
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. |
AW: 10.4 : Warum Inline-Variablen?
Ich kann auch gut ohne...
|
AW: 10.4 : Warum Inline-Variablen?
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/ |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Delphi-Quellcode:
Auf die Weise kann man Interfaces z.B. wieder aus dem Scope laufen lassen.
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; 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:
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Gruß K-H |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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. |
AW: 10.4 : Warum Inline-Variablen?
Du hast mich zu ernst genommen. Ist halt kein Killerfeature.
Gruß K-H |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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... |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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 ... |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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 |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
|
AW: 10.4 : Warum Inline-Variablen?
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:
Ich vermute mal das es nicht geht, weil dann verschachtelte Prozeduren damit nicht klarkommen.
var MyStdPowerSrc := TBattery.Create;
MyStdPowerSrc.Free ... var MyStdPowerSrc := TSolarPanel.Create; //wird hier der Typ TBattery gg. TSolarPanel getauscht ? MyStdPowerSrc.Free |
AW: 10.4 : Warum Inline-Variablen?
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:
|
AW: 10.4 : Warum Inline-Variablen?
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Delphi-Quellcode:
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).
var
tmp: Integer; begin for L := 1 to 10 do begin // tmp := 0; <-- Oder so was inc (tmp); DoStuff (L, tmp); end; 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... |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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:
My 2 cents...
{$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} ...:cat:... |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Allerdings dürfte der Anteil des Ansehens größerer Codeteile außerhalb von Delphi recht gering sein. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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ö. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
...:cat:... |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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... |
AW: 10.4 : Warum Inline-Variablen?
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:
|
AW: 10.4 : Warum Inline-Variablen?
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. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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. |
AW: 10.4 : Warum Inline-Variablen?
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. |
AW: 10.4 : Warum Inline-Variablen?
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.
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Delphi-Quellcode:
unit Unit1;
interface uses Unit2; ... ... begin var IstEinText := GetIstEinText; ... ... end;
Delphi-Quellcode:
Wahrscheinlich denkt man erst, es ist ein Boolean, aber Pustekuchen.
unit Unit2;
interface function GetIstEinText: string; implementation function GetIstEinText: string; begin Result := 'Ja, das ist ein Text.'; end; Damit wäre Folgendes obsolet: Zitat:
...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. |
AW: 10.4 : Warum Inline-Variablen?
@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. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
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. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:08 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz