10.4 : Warum Inline-Variablen?

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

[sakura]

Zitat von DasWolf:

Mauszeiger drüber, fertig!

Kostet zu viel Zeit

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:

{$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}

My 2 cents...

......

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

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