10.4 : Warum Inline-Variablen?

[Harry Stahl]

Zitat von DasWolf:

Zitat von Harry Stahl:

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 von Harry Stahl:

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

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 von Uwe Raabe:

Zitat von jaenicke:

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

......

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