Was nervt euch so, während der Programmierung oder so allgemein

[Delphi-Laie]

Zitat von jaenicke:

Globale Variablen habe ich nie (und würde ich sonst mit der Unit davor bezeichnen

Ich weiß, daß globale Variablen an sich schon recht verpönt sind (wenn auch nicht ganz so sehr wie das goto), so daß es sogar Programmiersprachen gibt, die sie gar nicht erst ermöglichen (dazu gibt es auch Beweise, daß trotzdem jeder Algorithmus realisierbar ist, soweit mir bekannt). Wie allerdings sonst prozedur-/funktionsübergreifend Informationen ausgetauscht werden sollen, ist mir rätselhaft. Für mich ist das ein relativ einfacher und unkomplizierter Weg, das zu bewerkstelligen. Genauso ist es mit dem goto. Break und exit z.B. sind auch nur etwas gehobene Versionen, das ach so verpönte goto auf Umwegen doch zu ermöglichen, denn es hat eben doch seine Existenzberechtigung.

Gut, wir müssen das in dieser "Meckerecke" nicht detaillieren und ausdiskutieren, sicher gibt es dazu auch einiges zu lesen.

Ach ja, und natürlich kann man Variablen so bezeichnen, daß einem das nicht passiert, genauso, wie überlicherweise Typen/Klassen auch ein vorangestelltes T erhalten (sollten), was aber nicht zwingend ist. Aber weder das eine noch das andere wird erzwungen, und wenigstens den warnenden Hinweis wegen dieser problempotentiellen doppelten Gleichbezeichnung hätte ich mir bei diesem sehr ausgereiften Compiler noch gewünscht.

[Medium]

Zitat von Delphi-Laie:

Wie allerdings sonst prozedur-/funktionsübergreifend Informationen ausgetauscht werden sollen, ist mir rätselhaft.

Parameter und brauchbares Klassendesign. Ich habe globale in C# nie vermissen müssen, weil ich es nie als für nötig empfand mir diese unter Delphi anzugewöhnen. Auch so Krücken wie Break, Continue und Exit kann man sich gerade unter Delphi einfach mal schenken, wenn man mit guten Bezeichnern verständliche Konditionen bastelt - unter C-likes ist zumindest das break für nicht-durchfallende case-Statements doch unverzichtbar.
Wenn es eine Warnung dafür geben sollte, müsste sie lauten "Lern es richtig zu machen!".

In Sachen "with" muss ich leider VB einen Gummipunkt verpassen: Durch den dort noch nötigen Punktoperator ist die Eindeutigkeit trotz ersparter Schreibarbeit und Beibehaltung der Übersichtlichkeit gegeben. So wie er in Delphi realisiert ist, nutze ich ihn maximal für im Code erstellte und initialisierte VCL Komponenten unter sehr definierten Bedingungen, und selten wenn weniger als 5-8 Zeilen dadurch kürzer würden. Sobald die implizite Referenz auf der "rechten Seite" auftaucht, qualifiziere ich jedoch immer zumindest bis auf den Klassen/-Instanznamen. Birgt zwar noch immer die Risiken die genannt wurden, jedoch ist unser Code nicht für andere Programmierer gedacht/zugänglich, und wenn es nicht mehr geht fällt es ohnehin auf mich zurück

[himitsu]

Mich nervt, daß es viele nette Dinge in Delphi gibt, die ich mir aber nie merken kann.

Statt einem WITH könnte man z.B. die Vorlage "VAR" nutzen, mit einem kurzen Variablennamen und arbeitet dann mit dieser Variable weiter.
Mir fällt aber auf, daß man dieses VAR noch erweitern könnte, um ein [var] :=[*]; .

[EWeiss]

Es ging bei with (VB6) nicht um ersparter Schreibarbeit sondern um Speicher zu sparen siehe 64K Limit pro Mod/Form das man wenn möglich einhalten sollte
(Win95 zeiten.)
Mittlerweile aber auch überholt.

gruss

[Popov]

Also nichts gegen With. Es liegt vielleicht daran, dass einige With nur gelegentlich nutzen, so dass, wenn sie es dann doch nutzen, schon mal Flüchtigkeitsfehler passieren. Ich habe aus gegebenem Anlass schon sehr früh damit angefangen. Nicht nur, dass ich With nutze, nicht selten nutze ich es auch so with Image1, Picture.Bitmap, Canvas, Pen, ClipRect do . Man muß im Kopf nur die Übersicht behalte, bzw. man muß paar Regeln beachten. Man muß wissen, dass sowohl Image1 , wie auch Bitmap ein Height haben. Dann muß man wieder runter und trotz With auch mal ein Image1.Height schreiben wenn man sich darauf bezieht. Wie gesagt, es ist eher eine Frage der Übung.

Was so daran übersichtlich sein?

Delphi-Quellcode:

 Image1.Picture.Bitmap.Canvas.Rectangle(
   Image1.Picture.Bitmap.Canvas.ClipRect.Left + 10,
   Image1.Picture.Bitmap.Canvas.ClipRect.Top + 15,
   Image1.Picture.Bitmap.Canvas.ClipRect.Right - 10,
   Image1.Picture.Bitmap.Canvas.ClipRect.Bottom - 15
   );

Das ist übersichtlicher, oder?

Delphi-Quellcode:

 with Image1.Picture.Bitmap.Canvas, ClipRect do
   Rectangle(Left + 10, Top + 15, Right - 10, Bottom - 15);

Wobei ich mich in der letzten Zeit auch schon mal dabei ertappe, dass ich es so schreibe:

Delphi-Quellcode:

var
  C: TCanvas;
  R: TRect;
begin
  ...

  C := Image1.Picture.Bitmap.Canvas;
  R := C.ClipRect;
  C.Rectangle(R.Left + 10, R.Top + 15, R.Right - 10, R.Bottom - 15);
end;

Es stimmt schon, wenn man nicht alleine an einem Code arbeitet, dann kann with schon unübersichtlich sein. Und beim Debuggen ist es tatsächlich schlimm, aber ich gehe immer davon aus, dass der Code ok ist und ich es nicht brauche. Und wenn, dann schriebe ich es für den Debugger um. Auch nicht wild.

[jaenicke]

Zitat von Popov:

Wobei ich mich in der letzten Zeit auch schon mal dabei ertappe, dass ich es so schreibe:

Ja, so schreibe ich das natürlich auch, nur mit etwas längeren Variablennamen. Ich schreibe das natürlich nicht wie in deinem ersten Beispiel.

Zitat von Popov:

Und beim Debuggen ist es tatsächlich schlimm, aber ich gehe immer davon aus, dass der Code ok ist und ich es nicht brauche.

Spätestens wenn man an größeren Projekten arbeitet, lernt man, dass man davon nie ausgehen kann. Selbst wenn alle Unittests klappen, irgendwo gibt es dennoch Fehler. Und ohne Unittests kann man von gar nichts ausgehen.

Aber ich hatte eben auch schon öfter solche Fälle wie in meinem Beispiel. Wo eben durch Änderungen in Delphi oder in fremden Codes plötzlich im besten Fall Compilerfehler entstehen oder im schlechtesten Fall einfach etwas nicht mehr korrekt funktioniert ohne dass man weiß warum. Das kann zwar immer passieren, aber es ist richtig ärgerlich, wenn man dann nach stundenlangen Korrekturen beim Einchecken feststellt, dass man eigentlich überall nur wegen with korrigieren musste...

Um bei deinem Beispiel zu bleiben:

Delphi-Quellcode:

with Image1.Picture.Bitmap.Canvas, ClipRect do
// Dummyzeile wegen dem Syntaxhighlighter...

Wenn du darin nun auch Width oder Height benutzt hättest, wäre das bis XE kein Problem gewesen. Nur hat TRect seit XE2 auch Width und Height. Und schon ist es nicht mehr eindeutig, ob das auf das Canvas oder auf ClipRect bezogen gemeint ist.

[Popov]

Das ist dann natürlich blöd, gebe ich zu. Obwohl ich Width und Height bei Rect schon so oft vermißt habe, dass es mich wundert, dass die so lange dafür gebraucht haben.

[himitsu]

Wobei ein benamtes WITH-Statemant auch was währe, so wie es beim ON-DO-Statement in einem Try-Except auch funktioniert.

Delphi-Quellcode:

with X: Edit1.Lines do
  X.Add('hallo);

oder with X := Edit1.Lines do oder with Edit1.Lines as X do (geht doch nicht)

[jaenicke]

Zitat von himitsu:

Wobei ein benamtes WITH-Statemant auch was währe, so wie es beim ON-DO-Statement in einem Try-Except auch funktioniert.

Dann benutze doch Prism. Da kannst du Variablen inline deklarieren.

Zitat von Popov:

Obwohl ich Width und Height bei Rect schon so oft vermißt habe, dass es mich wundert, dass die so lange dafür gebraucht haben.

Wie himitsu schon schrieb:

Zitat von himitsu:

Nja, wer konnte auch ahnen, daß man die Delphi2006-Features nun endlich auch mal delphiintern anwendet.

Wobei es in Delphi 2006 noch lange nicht alles so gab wie es für die Umsetzung in der Form wie in XE2 nötig ist.
Aber zumindest einiges hätte man natürlich auch da schon machen können.

Zitat von Bummi:

besonders schön sind Konstrukte wie

Oh ja, wie ich sowas liebe...

Am besten dann mit ein paar hundert Zeilen in so einem with.