Verbeserung bei Inline Variablen von 10.4 auf 11?

[jaenicke]

Zitat:

Zitat von Tristan90 (Beitrag 1518244)

Zitat:

Zitat von TurboMagic (Beitrag 1517251)

Der Plan ist m.W. das alte Refactoring durch was anderes zu ersetzen.

Klingt alles sehr vage.

Der LSP-Server wäre dafür ja ideal, wenn er denn zuverlässig funktionieren würde. Bevor damit das Refactoring umgesetzt werden kann, wird die Arbeit wohl erst dort nötig sein.

[idontknow]

Hatte gerade die Hoffnung, daß mit dem neuesten 11.3 Patch vielleicht auch die Inline-Variablen nun benutzbar wären, aber nein.

Sobald ich eine Inline-Variable benutze, kann ich Shift-Strg-V zum Deklarieren von Variablen vergessen...
Nehme ich dann alle Inline-Deklarationen aus dem Code, funktioniert es sofort wieder...

Aaarrghh!

[Tristan90]

Ich sehe das mittlerweile mit (Galgen-) Humor. Immerhin kann ich auf meinem nicht vorhandenen 4K+ Monitor programmieren :thumb:

Eingeschränkt funktionierende IDE bei Verwendung von Inline Variablen, Generics, anonymen Prozeduren/Funktionen und quasi jedem Feature, das eine moderne Sprache ausmacht ABER Unterstützung für macOS Ventura, die Hauptzielgruppe von Delphi und 4K+ Monitore :lol:

[freimatz]

Ich habe drei Monitore, davon zwei 4K. Die IDE funktioniert da leidlich gut.
Inline Vaiablen - freut Euch dass ihr nur solche Probleme habt. Ich habe für mich OutputDebugString wieder entdeckt weil ich nicht Debuggen kann (keine Breakpoints) :wall:

[himitsu]

Schön, wenn der Bugfix es nicht wirklich verbessert.
https://quality.embarcadero.com/browse/RSP-23056

Nichts zu sehen war nervig, aber etwas Falsches zu sehn, ist einfach nur *****.

[skybibo]

Die Idee von Inline Variablen finde ich im Prinzip sehr gut, solange jedoch die Seiteneffekte bei der Nutzung von Inline Variablen nicht gelöst sind, verzichte ich da lieber drauf.

[himitsu]

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

Und mein anderer Bug ist auch recht selten.
https://quality.embarcadero.com/browse/RSP-42368
Hier kommt es "auch" durch das Inline-Assembler, was hier im Zusammenhang wohl noch niemand getestet hatte.
Aber das betrifft auch nur Win32 ... Win64 kennt kein InlineAssembler mehr (nur ganze Methoden)

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1527182)

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:

Zitat von jaenicke (Beitrag 1527183)

Zitat:

Zitat von himitsu (Beitrag 1527182)

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