10.4 : Warum Inline-Variablen?

[Stevie]

Zitat:

Zitat von Heimlich (Beitrag 1465776)

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

So wie in dem verlinkten Vortrag gesagt wurde, wenn man seine Variablen m, k und w nennt, dann sollte man von Typinferenz die Finger lassen.
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.

[sakura]

Zitat:

Zitat von Stevie (Beitrag 1465788)

Zitat:

Zitat von Heimlich (Beitrag 1465776)

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

Ja, wenn ich meinen Krams nicht vernünftigt oder irreführend benenne, dann kann der Typ helfen, das zu richtig zu stellen.

Ich überlege gerade verzweifelt, wann ich das letzte Mal in einem Projekt ein Problem damit hatte, was für ein Typ magst Du sein...? Wenn musste ich deswegen in den var-Block schauen... das ist sehr, sehr lang her. Meistens ist es aus dem Kontext heraus eindeutig und dank guter Namen kein Problem. Klar, wenn ich in ein bestehenden Projekt einsteige und die ganzen Datentypen nicht kenne, dann mag man mal schauen, aber selbst dann sollte es sich schnell erledigen.

Von daher stimme ich Stevie vollends zu ;-)

...:cat:...

[Der schöne Günther]

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:

Oh, is that a

Delphi-Quellcode:

TFunc<IEnumerable<TPair<TFizzbuzz, TNiclausWirth>>>

in your pocket, or are you just happy to see me?

Grade so einen Typ nicht austippen zu müssen wenn man ihn z.B. eh nur weitergibt ist es schon wert 😎

[Harry Stahl]

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

[himitsu]

Zitat:

Zitat von Harry Stahl (Beitrag 1465989)

Damit entfällt z.B. der Compiler Hinweis

Komisch, ich hatte das nie,

aber hatte auch die IFDEFs ebenfalls im Variablenblock. :angle2:

[Harry Stahl]

Zitat:

Zitat von himitsu (Beitrag 1465990)

Zitat:

Zitat von Harry Stahl (Beitrag 1465989)

Damit entfällt z.B. der Compiler Hinweis

Komisch, ich hatte das nie,

aber hatte auch die IFDEFs ebenfalls im Variablenblock. :angle2:

Ja, meistens habe ich das auch, aber hin und wieder vergisst man das. Letztlich hat man dadurch mehr Schreibarbeit, da man schon im VAR Bereich u.U. mehrfach mit IFDEFS rum hantieren muss. Das entfällt jetzt.

Die Liste der positiven Auswirkungen wird immer länger...

[jfheins]

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.

[dummzeuch]

Zitat:

Zitat von jfheins (Beitrag 1466005)

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.

Wenn der Compiler das auch wirklich immer korrekt erkennen würde ...
Tut er aber nicht, auch wenn das tatsächlich von Version zu Version besser wird.

[Benmik]

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:

procedure TForm1.Button1Click(Sender: TObject);
begin
  var DateiListe := TDirectory.GetFiles('D:\Temp\', '*.*');
end;

funktioniert auch, wenn

Delphi-Quellcode:

System.Types

nicht in der Uses-Liste aufgeführt ist.

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:

begin

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

[wasbo]

Zitat:

Zitat von dummzeuch (Beitrag 1466007)

Zitat:

Zitat von jfheins (Beitrag 1466005)

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.

Wenn der Compiler das auch wirklich immer korrekt erkennen würde ...
Tut er aber nicht, auch wenn das tatsächlich von Version zu Version besser wird.

Der Thread ist ja schon ein wenig älter, aber gibt es ein konkretes Beispiel für dieses Verhalten, Delphi (Objekt-Pascal) ist doch eine typsichere Sprache???

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.

[himitsu]

Problem war ja eher, dass man bei der "normalen" Variablendeklaration nur globalen Variablen einen Initialwert mitgeben kann.

Wäre es auch bei Objekt-Feldern und lokalen Variablen möglich (k.A. warum die es nicht hinbekommen),
dann wäre es schon immer so nutzbar gewesen, wie man es jetzt bei den Inline-Variablen auch machen kann.

Ein Fortschritt war ja, dass bei statischen Array-Konstanten nun endlich die Länge automatisch bestimmt werden kann,
auch wenn es schon praktisch ist, dass in der Fehlermeldung steht, was ist und was es sein muß, wenn die Länge nicht stimmt.



Und eine Fehlerquelle weniger, gibt es nun dank Inline endlich auch.
Niemand kommt so mehr auf die Idee nach der For-Schleife auf die Variable zugreifen zu wollen.

Delphi-Quellcode:

for var i := 0 to 100 do

oder

Delphi-Quellcode:

for var V in ListOrSet do

, bzw selber den Typ angeben könnte man, falls man mag

Delphi-Quellcode:

for var i: Integer := 0 to 100 do

oder

Delphi-Quellcode:

for var V: Irgendwas in ListOrSet do

Und für per $IF/$IFDEF deaktivierbaren Test-/Debug-Code ist es absolut genial.

[Uwe Raabe]

Zitat:

Zitat von wasbo (Beitrag 1501380)

Aber der Pascal und Oberon Erfinder, Niklas Wirth, rät seinen Studenten, nach 25 Zeilen über eine neue Prozedur nachzudenken.

Robert C. Martin empfiehlt 4 - aber für Delphi würde ich das mal auf 6 - 8 erweitern.

[himitsu]

und in der Realität geht es dennoch in die Tausenden/Millionen :angle2:

[Frickler]

Zitat:

Zitat von Uwe Raabe (Beitrag 1501421)

Robert C. Martin empfiehlt 4 - aber für Delphi würde ich das mal auf 6 - 8 erweitern.

Bei 4 Zeilen frage ich mich doch, ob es ein Tool gibt, welches einem den Programmfluss visualisiert, wenn jede Funktion/Methode nur noch aus Aufrufen von anderen Funktionen/Methoden besteht. Denn ich habe solche Quelltexte schon gesehen und mich gefragt, "was macht das eigentlich"?

[Uwe Raabe]

Zitat:

Zitat von Frickler (Beitrag 1501462)

Bei 4 Zeilen frage ich mich doch, ob es ein Tool gibt, welches einem den Programmfluss visualisiert, wenn jede Funktion/Methode nur noch aus Aufrufen von anderen Funktionen/Methoden besteht. Denn ich habe solche Quelltexte schon gesehen und mich gefragt, "was macht das eigentlich"?

Wenn du dich das fragen musst, dann ist die Namensgebung der aufgerufenen Methoden offenbar nicht ganz so gut wie sie sein sollte.

[Stevie]

Robert C Martin nutzt auch nen Compiler, der vernünftigt inlined und WPO beherrscht :lol:

[Uwe Raabe]

Zitat:

Zitat von Stevie (Beitrag 1501526)

Robert C Martin nutzt auch nen Compiler, der vernünftigt inlined und WPO beherrscht :lol:

Implementation Detail :)