Verbeserung bei Inline Variablen von 10.4 auf 11?

[jaenicke]

Zitat von himitsu:

Funktionieren tut es ja.
https://quality.embarcadero.com/browse/RSP-23056 betrifft nur die Anzeige im Debugger.

Wobei ich gleiche Variablennamen trotz begrenztem Scope innerhalb der gleichen Methode ohnehin ziemlich unsauber finde.

[dummzeuch]

Zitat von jaenicke:

Zitat von himitsu:

Funktionieren tut es ja.
https://quality.embarcadero.com/browse/RSP-23056 betrifft nur die Anzeige im Debugger.

Wobei ich gleiche Variablennamen trotz begrenztem Scope innerhalb der gleichen Methode ohnehin ziemlich unsauber finde.

Delphi-Quellcode:

for var i := 0 to 50 do begin
  MachAMit(i);
end;
// ...
for var i := 0 to 10 do begin
  MachBMit(i);
end;

finde ich jetzt nicht wirklich unsauber.

[jaenicke]

Wenn man einen Variablennamen in der gleichen Methode für verschiedene Schleifen inline verwendet, sollte man auch mit dem Namen klarmachen, wofür diese Variable verwendet wird. Durch Inline-Variablen (abgesehen von Schleifen meinetwegen) leidet (wie man an diversen Quelltexten im Internet sieht) die Lesbarkeit ohnehin schon massiv, auch weil die Methoden oft länger werden. Wenn man dann noch schauen muss, wo das i für was verwendet wird und wo es für welchen Zweck deklariert wurde, wird es noch schlimmer.

Und wenn es "nur eine Schleifenvariable ist", bei der der Name egal ist, macht es noch weniger Sinn, den gleichen Namen zu verwenden.

Ich persönlich verwende Inline-Variablen nur, wenn es einen wichtigen Grund gibt. Zum Beispiel ist es praktisch, wenn man einen Quelltext zu Debugzwecken einfügt, wenn man dann nicht zwei Teile hat, die man hinterher wieder entfernen muss.

(Der zweite Grund, weshalb viele diese einsetzen, ist, damit sie nicht zur Deklaration springen müssen. Das kann mir nicht passieren, weil meine Methoden schlicht nicht so lang sind...)

[himitsu]

Ja, ich verwnde Inline gern für FOR
und sonst möglichst nur für kurze Mehrzeiler.

Aber auch für schnelle Test-/probecodes,
sowie für Democodes.

Auch kurze DebugCodes mit einem IFDEF oder einfach nur auskommentiert, da machen sich Inline-Variablen auch ganz schön, wenn sie sich nicht mit dem normalen Code oben im VAR vermischen und man auch dort nochmal IFDEF/Auskommentieren muß, damit nicht über nichtgenutzte Variablen gemeckert wird.



Ich hatte auch die Hoffnung, dass Inline wirklich nur dann vorhanden sind, wenn sie verwendet werden.

z.B. im DECMath wollte ich bei ParameterChecks die "komplexeren" Typen nur initialisieren/finalisieren, wenn sie nötig sind, und soll der Code möglichst ohne große Operationen am Stack schnell durchrauschen.
Dann könnte man den Convertierungszweizeiler schön im IF (begin-end) haben, anstatt ihn nochmal in eine Untermethode auslagern zu müssen.

[mytbo]

Zitat von jaenicke:

Ich persönlich verwende Inline-Variablen nur, wenn es einen wichtigen Grund gibt. Zum Beispiel ist es praktisch, wenn man einen Quelltext zu Debugzwecken einfügt, wenn man dann nicht zwei Teile hat, die man hinterher wieder entfernen muss.

Ich verwende Inline-Variablen in Quelltext-Beispielen, die ich veröffentliche. Würdest du auch die hier gezeigte Art der Anwendung negativ sehen? Der Grund, warum ich im Alltag Inline-Variablen nicht verwende, ist die Kompatibilität mit älteren Delphi Versionen. Grundsätzlich finde ich sie, nach einer kurzen Eingewöhnungsphase, dosiert eingesetzt, ganz praktisch.

PS: Die Länge der Funktion ist dem Demo-Charakter geschuldet.

Bis bald...
Thomas

[jaenicke]

Zitat von mytbo:

Ich verwende Inline-Variablen in Quelltext-Beispielen, die ich veröffentliche. Würdest du auch die hier gezeigte Art der Anwendung negativ sehen?
[..]
PS: Die Länge der Funktion ist dem Demo-Charakter geschuldet.

Das ist genau der Punkt. Bei einem solchen Beispiel möchte man alles in einem Stück zeigen, da kann ich es nachvollziehen, wenn man das so macht. Ich meine schon immer Produktivcode.

In einem echten Quelltext hätte ich z.B. statt docQuery.ToUrlEncode eine Funktion GetEncodedUrl oder so verwendet und hätte daher gar keine Variable mehr benötigt.

[mytbo]

Zitat von jaenicke:

Zitat von mytbo:

Ich verwende Inline-Variablen in Quelltext-Beispielen, die ich veröffentliche. Würdest du auch die hier gezeigte Art der Anwendung negativ sehen?
[..]
PS: Die Länge der Funktion ist dem Demo-Charakter geschuldet.

Das ist genau der Punkt. Bei einem solchen Beispiel möchte man alles in einem Stück zeigen, da kann ich es nachvollziehen, wenn man das so macht. Ich meine schon immer Produktivcode.

Ich setze Inline-Variablen in Quelltext-Beispielen seltener ein, als ich zuerst gedacht hatte. Hier habe ich ein Beispiel gefunden. Natürlich hat auch diese Funktion ein wenig Demo-Charakter. Frage ganz konkret:

Delphi-Quellcode:

var insRowIDs: TIDDynArray;
if restClient.BatchSend(insRowIDs) = HTTP_SUCCESS then
  Result := Length(insRowIDs);

Die Variable insRowIDs wird nur an dieser Stelle verwendet. Ist das kein guter Grund, es so lokal wie möglich zu halten? Die anderen Inline-Variablen stehen gleichfalls gut zuordenbar im Kontext der Anwendung. Wenngleich mein Urteil nicht neutral ist: Ich finde den Quelltext gut lesbar, auch durch den Einsatz der Inline-Variablen und deren strukturierenden Wirkung.

Bis bald...
Thomas

[himitsu]

Im C++, oder war's woanders, kannst'e auch Variablen mitten in der Bedingung von IF, WHILE usw. deklarieren.

Im Delphi sähe es dann so aus, falls wir irgendwann auch sowas können.

Delphi-Quellcode:

if restClient.BatchSend(var insRowIDs) = HTTP_SUCCESS then
  Result := Length(insRowIDs); 

//oder
if restClient.BatchSend(var insRowIDs: TIDDynArray) = HTTP_SUCCESS then
  Result := Length(insRowIDs); 


if GetValue(var Value) and (Value = 123) then

Gleich mal den Feature-Request erstellen.