AW: 10.4 : Warum Inline-Variablen?
Zitat:
Ja, wenn ich meinen Krams nicht vernünftigt oder irreführend benenne, dann kann der Typ helfen, das zu richtig zu stellen. Bei solchen Fällen frag ich den Entwickler beim Code review aber in aller Regel, ob er seine Variablen, Parameter sonstiges nicht lieber vernünftig benennen möchte. "Naming things" ist nicht umsonst eins der schwierigsten und oftmals falsch gemachten Dinge in der Softwareentwicklung. Aber als allgemeines Argument gegen Typinferenz ist es mMn unhaltbar. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Von daher stimme ich Stevie vollends zu ;-) ...:cat:... |
AW: 10.4 : Warum Inline-Variablen?
Ich kann es im Internet nicht mehr finden, ich meine es war zur Einführung von "auto" in C++11. Auf Delphi übertragen wäre es etwas wie
Zitat:
|
AW: 10.4 : Warum Inline-Variablen?
Weiterer positiver Umstand gerade von Inline vars gerade bei cross Plattform -Entwicklung festgestellt:
Eine Variable, die nur für eine bestimmte Plattform ({$IFDEF Linux ...) benötigt wird, wird auch nur in diesem IDFDEF Zweig definiert. Damit entfällt z.B. der Compiler Hinweis: Variable definiert, aber nicht verwendet, wenn ich die Windows-Versino kompiliere. Außerdem entfällt auch die Warnung, dass eine bestimmte Variable Plattformspezifisch sei wenn Sie außerhalb der Plattform definiert wurde... |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
aber hatte auch die IFDEFs ebenfalls im Variablenblock. :angle2: |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Die Liste der positiven Auswirkungen wird immer länger... |
AW: 10.4 : Warum Inline-Variablen?
Um nochmal auf den Titel einzugehen:
Ich habe schon länger nicht mehr Delphi programmiert, aber das eigentlich tolle an den inline vars ist doch: Initialisierung bei Deklaration. Eine Variable mit undefiniertem Inhalt ist doch eigentlich unbrauchbar (bis zur Initialisierung). Dass das jetzt in einer Zeile passieren kann, macht das ganze einfach lesbarer und aufgeräumter. Und dass der Zugriff darauf nur einer Warnung ist, finde ich auch nur mäßig sinnvoll. Wenn die nicht sicher initialisiert wird, sollte der Code nicht kompilieren. Schluss aus. |
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Tut er aber nicht, auch wenn das tatsächlich von Version zu Version besser wird. |
AW: 10.4 : Warum Inline-Variablen?
In den Links, die Harry Stahl angegeben hat, findet sich auch der Hinweis von Stefan Glienke, dass bei einer inline deklarierten Variable die Unit, in der der Typ der Variable deklariert wird, nicht mehr zwingend in der Uses-Angabe aufgeführt sein muss:
Delphi-Quellcode:
funktioniert auch, wenn
procedure TForm1.Button1Click(Sender: TObject);
begin var DateiListe := TDirectory.GetFiles('D:\Temp\', '*.*'); end;
Delphi-Quellcode:
nicht in der Uses-Liste aufgeführt ist.
System.Types
Aus Sicht eines Hobbyprogrammierers finde ich die Kleinlichkeit, die Konstruktionsmerkmal von Pascal ist, in aller Regel eher hilfreich, weil sie zu einem Mindestmaß an Genauigkeit und Strukturiertheit zwingt. Ich könnte mir allerdings vorstellen, die var-Liste sozusagen über
Delphi-Quellcode:
hinaus fortzuführen, um initialisierte Variablen zu bekommen (und würde dabei immer den Typ angeben). Und vielleicht noch bei Schleifen. Ansonsten war die Sache mit dem Gültigkeitsbereich kaum je eine Quelle von Fehlern (da gibt es massenhaft andere Quellen).
begin
|
AW: 10.4 : Warum Inline-Variablen?
Zitat:
Für die Übersichtlichkeit, ist der Ort der Variablen-Definition eh unbedeutend, eine gute Prozedur oder Funktion sollte nicht länger als 25 Zeilen sein. Ausnahmen bestätigen natürlich die Regel. Aber der Pascal und Oberon Erfinder, Niklas Wirth, rät seinen Studenten, nach 25 Zeilen über eine neue Prozedur nachzudenken. Die Initialisierung der Inline-Variablen bei der Deklaration ist eine der größten Stärken. Member-Variablen von Objekten sind definiert, auch wenn sie Nil sind. Aber lokale Variablen leider nicht. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 04:30 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