10.4 : Warum Inline-Variablen?

**sakura**

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

...

**Harry Stahl**

Zitat von sakura:

Zitat von Harry Stahl:

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

...

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 von sakura:

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 von Hobbycoder:

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 von Lemmy:

Zitat von Hobbycoder:

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 von Hobbycoder:

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 von Moombas:

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:

markieren

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.

**Heimlich**

Zitat von Moombas:

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:

zusammenfalten · markieren

Delphi-Quellcode:

			unit Unit1;

interface

  uses Unit2;

...

...

begin

  var IstEinText := GetIstEinText;

 ...

 ...

end;

zusammenfalten · markieren

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 von Stevie:

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.