Wo fügt die IDE ein ON-Event ein?

[Medium]

Perlsau, du spricht aus, was ich beim Lesen dieses Threads dachte. Ich hätte es auch am aller liebsten, wenn die Completion immer so einfügt, wie es im Deklarationsteil sortiert ist. Am besten auch noch nach Sichtbarkeit gruppiert. Und beim Implementieren abgeleiteter Methoden diese auch in der Reihenfolge in der sie in der Basisklasse deklariert sind, jedoch vor allen in der aktuellen deklarierten.
Gerade bei Get* und Set* macht mich das immer "traurig", weil ich viel lieber Getter und Setter einer Property besammen habe, statt aller Getter und dann alle Setter.

[Perlsau]

Genau dort nervt mich diese wilde Platzierung von Methoden ganz besonders. Daher hab ich mir angewöhnt, nicht nur bei Properties immer nur eine Deklaration auf einmal zu machen, dann bleibt die Sucherei im Rahmen. Auch bei der automatischen Deklaration von Komponenten-Ereignissen (Aktionslisten, Buttons usw.) nervt die Sucherei. Mit meinem Sortierschema verschwende ich keine Zeit damit, die nächste Buttonklick-Methode zu finden oder erst einmal zum Anfang der Unit springen zu müssen, um die nächste Methode mit Strg-Mausklick zu sehen. Dabei wäre es sicher irgendwie möglich, die Deklaration von Komponenten-Methoden und die entsprechenden Methoden, die man erzeugt, so anzuordnen, wie die Komponenten im Interface-Teil angeordnet sind:

Delphi-Quellcode:

TYPE
  TFormMain = CLASS(TForm)
    AktionsListe               : TActionList;
    AL_DB_Login                : TAction;
    AL_DB_Logout               : TAction;
    AL_DB_NewUser              : TAction;
    AL_DB_Close                : TAction;
    AL_ED_Append               : TAction;
    AL_ED_Delete               : TAction;
    AL_ED_Edit                 : TAction;
    AL_ED_Post                 : TAction;
    AL_ED_Cancel               : TAction;
    AL_ED_Open                 : TAction;
    AL_ED_Save                 : TAction;
    AL_ED_Print                : TAction;
    AL_ED_Find                 : TAction;

    HauptMenu                  : TJvMainMenu;
    HM_DB                      : TMenuItem;
    HM_DB_Close                : TMenuItem;
    HM_DB_Login                : TMenuItem;
    HM_DB_Logout               : TMenuItem;
    HM_DB_NewUser              : TMenuItem;
    HM_DB_1                    : TMenuItem;
    HM_ED                      : TMenuItem;
    HM_ED_Append               : TMenuItem;
    HM_ED_Delete               : TMenuItem;
    HM_ED_Edit                 : TMenuItem;
    HM_ED_Post                 : TMenuItem;
    HM_ED_Cancel               : TMenuItem;
    HM_ED_1                    : TMenuItem;
    HN_ED_Open                 : TMenuItem;
    HM_ED_Save                 : TMenuItem;
    HM_ED_Print                : TMenuItem;
    HM_ED_Find                 : TMenuItem;

    StatBarMain                : TJvStatusBar;

    Panel_Navi                 : TPanel;
    BitNavi_Append             : TJvBitBtn;
    BitNavi_Delete             : TJvBitBtn;
    BitNavi_Edit               : TJvBitBtn;
    BitNavi_Post               : TJvBitBtn;
    BitNavi_Cancel             : TJvBitBtn;
    BitNavi_Load               : TJvBitBtn;
    BitNavi_Save               : TJvBitBtn;
    BitNavi_Print              : TJvBitBtn;
    BitNavi_Find               : TJvBitBtn;
    BitNavi_Close              : TJvBitBtn;

    PgCtrl_Main                : TJvPageControl;
    TS_Zentrale                : TTabSheet;
    TS_Recherche               : TTabSheet;
    PgCtrl_Recherche           : TJvPageControl;
    TS_Recherchieren           : TTabSheet;
    TS_Kategorien              : TTabSheet;

    TS_Land                    : TTabSheet;
    PgCtrl_Land                : TJvPageControl;
    TS_Kontinente              : TTabSheet;
    Panel_Kontinent            : TPanel;
    DBGrid_Kontinent           : TJvDBGrid;
    DBImg_Kontinent            : TJvDBImage;
    Panel_KontinentEdit        : TPanel;
    DBEd_Kontinent             : TJvDBMaskEdit;
    DBSpin_Kontinent_Flaeche   : TJvDBSpinEdit;
    DBSpin_Kontinent_Einwohner : TJvDBSpinEdit;
    DBSpin_Kontinent_Dichte    : TJvDBSpinEdit;
    DBSpin_Kontinent_Laender   : TJvDBSpinEdit;
    DBRich_Kontinent           : TJvDBRichEdit;
    Lbl_Kontinent              : TLabel;
    Lbl_Kontinent_Flaeche      : TLabel;
    Lbl_Kontinent_Einwohner    : TLabel;
    Lbl_Kontinent_Dichte       : TLabel;
    Lbl_Kontinent_Laender      : TLabel;

    TS_Staaten                 : TTabSheet;
    DBGrid_Staaten             : TJvDBGrid;
    Split_Staaten              : TJvSplitter;
    Panel_Staaten              : TPanel;
    DBEd_Staaten_Staat         : TJvDBMaskEdit;
    DBLU_Staaten_Waehrung      : TJvDBLookupCombo;
    DBLU_Staaten_Kontinent     : TJvDBLookupCombo;
    DBEd_Staaten_Hauptstadt    : TJvDBMaskEdit;
    DBEd_Staaten_Wiki          : TJvDBMaskEdit;
    DBSpin_Staaten_Einwohner   : TJvDBSpinEdit;
    DBEd_Staaten_KFZ           : TJvDBMaskEdit;
    DBEd_Staaten_Vorwahl       : TJvDBMaskEdit;
    DBEd_Staaten_TLD           : TJvDBMaskEdit;
    DBEd_Staaten_HDI           : TJvDBMaskEdit;
    DBEd_Staaten_Iso           : TJvDBMaskEdit;
    DBRich_Staaten             : TJvDBRichEdit;
    DBImg_Staaten_Wappen       : TJvDBImage;
    DBImg_Staaten_Flagge       : TJvDBImage;
    Lbl_Staaten_Staat          : TLabel;
    Lbl_Staaten_Kontinent      : TLabel;
    Lbl_Staaten_Waehrung       : TLabel;
    Lbl_Staaten_Hauptstadt     : TLabel;
    Lbl_Staaten_Wiki           : TLabel;
    Lbl_Staaten_Einwohner      : TLabel;
    Lbl_Staaten_KFZ            : TLabel;
    Lbl_Staaten_Vorwahl        : TLabel;
    Lbl_Staaten_TLD            : TLabel;
    Lbl_Staaten_HDI            : TLabel;
    Lbl_Staaten_Iso            : TLabel;

    TS_Waehrungen              : TTabSheet;
    DBGrid_Waehrung            : TJvDBGrid;
    Split_Waehrung             : TJvSplitter;
    Panel_Waehrung             : TPanel;
    DBEd_Waehr_Waehrung        : TJvDBMaskEdit;
    Lbl_Waehr_Waehrung         : TLabel;
    DBLU_Waehr_Einheit         : TJvDBLookupCombo;
    DBLU_Waehr_Einteilung      : TJvDBLookupCombo;
    DBLU_Waehr_Kuerzel         : TJvDBMaskEdit;
    DBDate_Waehr_Datum         : TJvDBDateEdit;
    TimeEd_Waehr_Zeit          : TJvTimeEdit;
    DBSpin_Waehr_Kurs          : TJvDBSpinEdit;
    DBLU_Waehr_Iso             : TJvDBMaskEdit;
    DBLU_Waehr_IsoNum          : TJvDBMaskEdit;
    Check_WaehrungPics         : TCheckBox;
    DBRich_Waehrung            : TJvDBRichEdit;
    Lbl_Waehr_Einheit          : TLabel;
    Lbl_Waehr_Einteilung       : TLabel;
    Lbl_Waehr_Kuerzel          : TLabel;
    Lbl_Waehr_Iso              : TLabel;
    Lbl_Waehr_IsoNum           : TLabel;
    Lbl_Waehr_Kurs             : TLabel;
    Lbl_Waehr_Datum            : TLabel;
    Lbl_Waehr_Zeit             : TLabel;

    TS_Kurse                   : TTabSheet;
    TS_Optionen                : TTabSheet;

[Namenloser]

Zitat von Medium:

Ich hätte es auch am aller liebsten, wenn die Completion immer so einfügt, wie es im Deklarationsteil sortiert ist.

Oh Gott, ja! Aber nicht nur Delphi braucht dieses Feature, andere IDEs auch.

Ich hab es inzwischen leider aufgegeben, die Routinen im Implementierungsteil von Hand zu sortieren. Inzwischen ist mir alles egal, die liegen da einfach nur noch kreuz und quer... (allerdings zumindest nach Klassen gruppiert). Wenn ich etwas bestimmtes suche, gehe ich den Umweg über das Interface oder Strg+F muss herhalten.

[stahli]

Ich hab´s auch aufgegeben: http://www.delphipraxis.net/180583-m...ihenfolge.html

[Dejan Vu]

Der verständlich Drang, Ordnung is Chaos einer TForm-Unit zu bringen, ist verständlich.
Aber wenn man Frames nähme, würden sich die Probleme hier gar nicht so stark äußern, denn dann hätte man auch in der UI das SRP weitestgehend abgebildet: Jeder einzelne Frame wäre dann so übersichtlich, das man auf eine logische Gruppierung der vielleicht 5-10 Events verzichten könnte, zudem die IDE einem sehr komfortable Navigationshilfen bietet.

Jedenfalls wäre ein TForm-Ungetüm in der Art

Delphi-Quellcode:

TYPE
  TFormMain = CLASS(TForm)
    AktionsListe               : TActionList;
    ...
    // gefühlte 100 Zeilen später
  end;

per se aufgeräumter (Deklaration und Code)

Delphi-Quellcode:

TYPE
  TFormMain = CLASS(TForm)
    Aktion : TActionFrame;
    HauptMenu : TMenuFrame;
    Buttons : TButtonFrame;
    Staaten : TStaatenFrame;
    Waehrungen : TWaehrungenFrame;
    StatBarMain : TJvStatusBar;
...
  end;

Auch werden hier kaum noch Events bedient (außer die der Form, versteht sich). Und ob man da denn nun wirklich die alphabetische Reihenfolge *benötigt*, sei mal dahingestellt, obwohl der Codeformatter einem das ja anständig aufräumt.

Eine aufgeräumte UI geht aber nur bei aufgeräumtem Model (Klassen), womit es folgerichtig fast unmöglich ist, seinen Spaghetticode nachträglich so aufzuräumen, Andererseits ist es aber sehr praktisch: Fängt man an, sich zu zwingen, die UI in einzelne Komponenten/Frames nach dem SRP-Prinzip zu unterteilen, landet man zwangsläufig bei aufgeräumtem Code. Man kotzt so lange rum, bis alles irgendwie passt, und man bei etwas Ähnlichem wie MVVM landet. Man kann ja nicht aus einem Frame einfach die Funktion eines anderen Frames aufrufen, denn die kennen sich ja nicht mehr: Im Gegensatz zum Spaghetti-Form, wo Menu_fooBar durchaus Lbl_Schießmichtot kennt.
Frame A kennt nur das VM, aber Frame B auch und wenn nun A im VM rumändert, kann das VM dies über ein Notify-Event publizieren und Frame B kann sich entsprechend updaten.

Allerdings verlässt man dann das R vom RAD (Rapid Application Development) und arbeitet eher im SACADWALOC (Slow and Clean Application Development with a lot of Code) Bereich. Vorteil ist dann aber, das die Maintenance, Skalierbarkeit und Erweiterbarkeit wesentlich nachhaltiger ist. Aber das Wichtigste ist (meine Erfahrung): Beim MVVM verstehen auch andere Programmierer, was man meint.

[stahli]

Das ist schon richtig, aber selbst in einem Frame oder bei einer Komponentenentwicklung würde ich mir eine übersichtlichere Strukturierung wünschen.

Zuerst gehören (wenn man schon immer eine komplette Unit im Editor hat) m.E. die Kontruktoren und Destruktoren und danach alle Methoden in der Reihenfolge der Deklaration, wobei eine explizite Zusammenfassung der Getter und Setter jeweils noch sinnvoller wäre.

Wenn das Delphi optional anbieten würde wäre das eine nützliche Sache und auch nicht störend, weil man es dann ja ausschalten könnte.

[Sir Rufo]

Auch ich empfinde es als störend, denke dann an die Fliege im Urinal und sage mir "Ist doch auch egal"

[Dejan Vu]

Früher dachte ich, ich könnte ohne meine eigene -ganz spezielle- Codeformatierung nicht leben. Ich habe Stunden damit verbracht, meinen Code per Hand zu formatieren.

Irgendwann habe ich mir einmal diverse Codeformatierer angeschaut und bin bei einem hängengeblieben, den man sogar mit D6 verwenden konnte. Der hat ca. 90% meiner Formatierung umsetzen können und ich dachte damals: "Probiere doch einfach mal aus, ob Du mit den fehlenden 10% leben kannst".

Kann ich.

Heute weiß ich: Codeformatierung und -sortierung werden überbewertet. Konventionen, die automatisch (d.h. durch einen Formatierer) eingehalten werden, sind ausreichend.

Wichtiger als Codeformatierung und -sortierung ist eh der Code selbst, also die Einhaltung der wichtigsten Prinzipien (SOLID, DRY, KISS, der ganze Käse halt) sowie die Nomenklatur, also die Art und Weise, wie Bezeichner -äh- bezeichnet werden.

Das ist ein bisschen so wie die Diskussion um Bier aus Dosen, Flaschen oder Zapfhähnen, Material von Lautsprecherkabeln oder ob die Farbe eines Autos etwas mit der Höchstgeschwindigkeit zu tun hat. Wichtige Stammtischthemen, aber irgendwie doch marginal.

Meine Meinung.

Zitat von stahli:

Wenn das Delphi optional anbieten würde wäre das eine nützliche Sache und auch nicht störend, weil man es dann ja ausschalten könnte.

Das ist natürlich richtig. Ausschalten würde ich es auch nicht.

[himitsu]

Bin ich nicht der Meinung.

Vorallem wenn man den Code selbst für die Dokumentation verwendet, dann ist eine gewisse Ordnung schon von nöten.

[Dejan Vu]

Zitat von himitsu:

Bin ich nicht der Meinung.

Für dich kommt dann also an erster Stelle der sortierte und formatierte Code. Einhaltung von Code-Pattern, ordentliche Namen für Methoden und Variablen sind dann zweitrangig. Also: Aussehen ist wichtiger als Qualität? Schminkst Du dich auch?

Lies nochmal genau: Ich sage nicht, das das überflüssig ist, sondern zweitrangig. Sekundäres Sortierkriterium sozusagen.

Mir reicht die Sortierfunktion von Resharper, auch, weil ich genau angeben kann, wie ich sortieren will. Trotzdem ist der Code wichtiger, denn wenn ich z.B. den Code komplett umsortiere, spielt die Diff-Funktion des SVN verrückt bzw. sagt mir (zu Recht), das sich der komplette Code verändert hat. In der Folge sortieren wir nur sehr selten, was zur Folge hat, das man auch nicht drauf achtet und es auch nicht benötigt, was widerum bei anzustrebenden kleinen Klassen dann auch wieder höchstens zweitrangig ist, weil eine gute Klasse per se übersichtlich ist.