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

[DelTurbo]

Hallo,
ich versuche in meinen sachen immer die On-Events zusammen zu halten. Wenn ich z.b. einen Doppelklick auf FormClose mache, fügt er das dem Alphabet nach ein. Also z.b. nach FormActivate.

Wenn ich nun eigene Subs habe, dann haut er das mitten rein. Halt dem Alphabet nach. Kann man diese verhalten beeinflussen?

Vielen dank im voraus

[daywalker9]

Ja, wird es wohl bald geben - Andreas Hausladen hat da mal wieder was gebastelt :)

[Perlsau]

Bei mir (Delphi 2009) fügt die IDE Methoden manchmal sogar so querbeet ein, daß gleich darauf eine Fehlermeldung mit dem Hinweis, die Methode wurde nicht gefunden, erscheint. Dann weiß ich sofort, daß die Methode mal wieder mitten in einen Kommentar eingefügt wurde :cyclops:

Hab' mich aber dran gewöhnt und komme damit klar. Meine Methoden sortiere ich immer gleich händisch.

[DelTurbo]

Zitat:

Zitat von daywalker9 (Beitrag 1267123)

Ja, wird es wohl bald geben - Andreas Hausladen hat da mal wieder was gebastelt :)

Geil, genau sowas suche ich. Ohne das DDevExtensions wäre das leben mit Delphi 1.000 mal schwerer :thumb:

Dann versuche ich mich mal in gedult zu üben. Wird wohl hoffentlich auch für 2007 kommen.

[jbg]

Zitat:

Zitat von DelTurbo (Beitrag 1267130)

Dann versuche ich mich mal in gedult zu üben. Wird wohl hoffentlich auch für 2007 kommen.

Unwahrscheinlich, da ich kein Delphi 2007 installiert habe und DDevExtensions schon seit 2011 nur noch Delphi 2009 und neuer unterstützt.

[DelTurbo]

Zitat:

Zitat von jbg (Beitrag 1267210)

Unwahrscheinlich, da ich kein Delphi 2007 installiert habe und DDevExtensions schon seit 2011 nur noch Delphi 2009 und neuer unterstützt.

Schade eigentlich... naja, kann man nix machen. Dann muss ich weiter von Hand fummeln, wie Perlsau.

Trotzdem sind die DDevExtensions geil.

EDIT: Wie sucht die IDE eigentlich? Ich bekomme das nicht raus. Ich habe schon versuche mit Dummy Proceduren was zu machen. z.b. procedure XXXX und hoffte das er davor einfügt. Macht er aber nicht.

[jbg]

Zitat:

Zitat von DelTurbo (Beitrag 1267254)

EDIT: Wie sucht die IDE eigentlich?

Die IDE sucht nach "{ Klassenname }" und dann versucht sie herauszufinden, ob die existierenden Methoden bereits sortiert sind und fügt dann die neuen Methoden ein. Das scheint aber alles irgendwie nicht immer ganz korrekt abzulaufen.

[himitsu]

Und ich dachte immer die gehn ganz doof von oben nach unten die implementierten Methoden durch und wenn sie Eine finden, deren Name >= der Einzufügenden ist, dann kommt das davor, bzw. hinten den letzen Fund. :stupid:

[Perlsau]

Für meine Zwecke bzw. mein Sortierschema wäre es sinnvoll, wenn eine neue Methode, die ich z.B. via Shift-Ctrl-C erstelle, genau dort eingefügt wird, wo analog dazu die Methodendeklaration steht. Meine Sortierung sieht meist so aus:

Delphi-Quellcode:

    Procedure FormCreate(Sender                  : TObject);
    Procedure FormShow(Sender                    : TObject);
    Procedure FormActivate(Sender                : TObject);
    Procedure FormCloseQuery(Sender              : TObject; var CanClose: Boolean);
    Procedure FormClose(Sender                   : TObject; var Action: TCloseAction);
    Procedure FormDestroy(Sender                 : TObject);

    Procedure PgCtrl_MainChange(Sender           : TObject);
    Procedure PgCtrl_RechercheChange(Sender      : TObject);
    Procedure PgCtrl_LandChange(Sender           : TObject);
    Procedure DBGrid_KontinentColumnMoved(Sender : TObject; FromIndex, ToIndex: Integer);
    Procedure DBGrid_StaatenColumnMoved(Sender   : TObject; FromIndex, ToIndex: Integer);
    Procedure DBGrid_WaehrungColumnMoved(Sender  : TObject; FromIndex, ToIndex: Integer);
    Procedure DBGrid_KontinentTitleClick(Column  : TColumn);
    Procedure DBGrid_StaatenTitleClick(Column    : TColumn);
    Procedure DBGrid_WaehrungTitleClick(Column   : TColumn);
    Procedure DBRich_KontinentURLClick(Sender    : TObject; const URLText: string; Button: TMouseButton);
    Procedure DBRich_StaatenURLClick(Sender      : TObject; const URLText: string; Button: TMouseButton);
    Procedure DBRich_WaehrungURLClick(Sender     : TObject; const URLText: string; Button: TMouseButton);

    Procedure Panel_StaatenResize(Sender         : TObject);
    Procedure Panel_WaehrungResize(Sender        : TObject);

    Procedure Lbl_Staaten_WikiDblClick(Sender    : TObject);
    Procedure Check_WaehrungPicsClick(Sender     : TObject);

    Procedure AL_DB_LoginExecute(Sender          : TObject);
    Procedure AL_DB_LogoutExecute(Sender         : TObject);
    Procedure AL_DB_NewUserExecute(Sender        : TObject);
    Procedure AL_DB_CloseExecute(Sender          : TObject);
    Procedure AL_ED_AppendExecute(Sender         : TObject);
    Procedure AL_ED_DeleteExecute(Sender         : TObject);
    Procedure AL_ED_EditExecute(Sender           : TObject);
    Procedure AL_ED_PostExecute(Sender           : TObject);
    Procedure AL_ED_CancelExecute(Sender         : TObject);

Die Reihenfolge der Form-Ereignisse entspricht der Reihenfolge ihres Auftretens. Die Reihenfolge der untenstehenden ActionList-Ereignisse entspricht einerseits der Reihenfolge in der Actionlist, andererseits auch der Reihenfolge in den entsprechenden Menüs. Ebenso entspricht die Reihenfolge der PageControl-Ereignisse der Reihenfolge, in der die Pagecontrols im Formular angeordnet sind. Ob man das automatisiert anordnen kann, bezweifle ich, und wenn, dann nur mit enorm hohem Aufwand. Leider muß ich eben nicht nur die Methoden-Deklarationen im Interface-Abschnitt von Hand sortieren, sondern immer auch die Methoden im Implementation-Abschnitt. Aber was soll's, ich hab mir das längst angwöhnt und mach's inzwischen fast automatisch.

[Der schöne Günther]

Ich habe überhaupt keine Sortierung. Ich packe die Deklarationen der VCL-Eventhandler sogar noch immer in eine Region damit ich sie nicht sehen muss :stupid:

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

Zitat von Medium (Beitrag 1267280)

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

Delphi-Quellcode:

Menu_fooBar

durchaus

Delphi-Quellcode:

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:

Zitat von stahli (Beitrag 1267333)

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:

Zitat von himitsu (Beitrag 1267352)

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? :mrgreen:

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.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1267361)

Zitat:

Zitat von himitsu (Beitrag 1267352)

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?

Die Tatsache, daß mancher deine Ansichten und Meinungen nicht teilt, berechtigt dich meiner Meinung nach nicht dazu, Beleidigungen wie z.B. die herabsetzende Frage, ob Himitsu sich schminkt, auszustoßen. Himitsu hat nirgends geschrieben, daß für ihn Codeformatierung wichtiger sei als saubere Programmierung. Diese Interpretation seiner Ausführungen stammt allein von dir. Mir z.B. sind saubere Programmierung (z.B. aussagefähige Bezeichner) genau so wichtig wie die übersichtliche Darstellung des Codes. Da gibt es keinen zweiten Rang.

Ich empfinde es als störend, daß du jede sich bietende Gelegenheit dazu benutzten mußt, andere herabzusetzen.

[p80286]

Nun, ein optisch aufgeräumter Code erleichtert dem Lesenden sich zu orientieren. Nicht umsonst gab es mal den Beruf des Setzers, der die Inhalte der Redakteure in eine optisch ansprechende und leicht erfassbare Form gebracht hat. Ob alle Getter und alle Setter zusammengehören oder die Sortierung nach Properties erfolgen sollte, ist von den einzelnen Vorlieben/Denkweisen abhängig aber "Kraut und Rüben" halte ich für nicht so gelungen.

Gruß
K-H

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1267365)

...

Misch dich doch nicht immer in die Angelegenheiten anderer ein. Dankeschön.

Zitat:

Zitat von p80286 (Beitrag 1267368)

Nun, ein optisch aufgeräumter Code erleichtert dem Lesenden sich zu orientieren. ...aber "Kraut und Rüben" halte ich für nicht so gelungen.

Wer findet das schon?

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1267369)

Zitat:

Zitat von Perlsau (Beitrag 1267365)

...

Misch dich doch nicht immer in die Angelegenheiten anderer ein. Dankeschön.

Vor allem soll ich mich wohl in deine "Angelegenheiten" nicht einmischen, nicht wahr? Erinnert mich an den einen User, der von mir verlangt hat, ich solle mich aus allen Threads, in denen er auftritt, doch bitte heraushalten. Das ist lächerlich!

Doch bedenke: Wenn du einen hiesigen User fragst, ob er sich schminkt, mischst du selbst dich in die Angelegenheiten eines anderen ein, denn – mal ganz davon abgesehen, daß eine solche Bemerkung beleidigend ist und mit der diskutierten Thematik absolut nichts zu tun hat – geht es dich überhaupt nichts an, ob er sich schminkt oder nicht. Ergo solltest du, bevor du ungebeten derartige "Ratschläge" erteilst, diese erst einmal selbst befolgen.

Davon abgesehen wendest du hier die rabulistische Methode des Strohmannes an: Du argumentierst nicht am eigentlichen Diskussionsobjekt, sondern stellst die These auf, daß wenn man deine Meinung nicht teile, man sich wohl (als Mann – wohlgemerkt!) auch schminken würde, alles aufgebaut auf deiner fragwürdigen und fast schon böswilligen Interpretation einer völlig anders intendierten Aussage. Deine unwirsche Abwehrreaktion ist natürlich nachvollziehbar, da du dich bei einem moralisch fragwürden Handeln ertappt fühlst. Andererseits könntest du statt Empöprung und Verärgerung zu induzieren auch mal versuchen, Verständnis zu entwickeln, das würde letztlich deine Sensibilität für die Empfindungen anderer etwas voranbringen.

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1267371)

Wenn du einen hiesigen User fragst, ob er sich schminkt, ...

Ich gehe davon aus, das er den :mrgreen: nach meiner gar chelmichen Frage im Gegensatz zu Dir schon entsprechend interpretiert.

Und über den Rest deiner Äußerungen decke ich den Mantel der Nächstenliebe.

[Perlsau]

Zitat:

Zitat von Dejan Vu (Beitrag 1267372)

Zitat:

Zitat von Perlsau (Beitrag 1267371)

Wenn du einen hiesigen User fragst, ob er sich schminkt, ...

Ich gehe davon aus, das er den :mrgreen: nach meiner gar chelmichen Frage im Gegensatz zu Dir schon entsprechend interpretiert.

Wenn ich dich jetzt fragen würde, ob du heut' schon deine Medikamente genommen hast :lol: und dahinter einen Smiley hänge, wäre das durch den Smiley dann weniger beleidigend? Letzterer soll doch dir doch nur einen Vorwand liefern, dich herauszureden und den derart Beleidigten davon abhalten, sich zu beschweren – er könnte ja als überempfindlich oder Spaßbremse etikettiert werden. Der Smiley ändert jedoch weder etwas an der beleidigenden Äußerung noch daran, daß du hier Usern Dinge "in den Mund legst", die sie so nie geäußert haben.

Zitat:

Zitat von Dejan Vu (Beitrag 1267372)

Und über den Rest deiner Äußerungen decke ich den Mantel der Nächstenliebe.

Ja, ich verstehe, deine Postings triefen nur so vor Nächstenliebe, deshalb bist du ja auch bereits wegen Beleidigung verwarnt worden, nicht wahr :twisted:

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1267377)

Wenn ich dich jetzt fragen würde, ob du heut' schon deine Medikamente genommen hast :lol: und dahinter einen Smiley hänge, wäre das durch den Smiley dann weniger beleidigend?

Natürlich. Ich würde schmunzeln, denn ich wüsste, Du wolltest mich nicht 'beleidigen'. Das ist ja gerade der *Sinn* dieser Smileys. Im echten Leben würde sich das 'Zwinkern' nennen, oder 'lachen und auf die Schulter fassen', oder nur 'lachen', 'lächeln' oder etwas in der Art. Du verstehst, was ich meine: Nonverbale Kommunikation.

Zitat:

deshalb bist du ja auch bereits wegen Beleidigung verwarnt worden, nicht wahr :twisted:

Bin ich? Das wäre mir neu.

So, lassen wir das jetzt? Oder machst Du weiter? Dann bitte nur noch per PN.

Hast Du eigentlich noch etwas zum eigentlichen Thema beizusteuern? Bevorzugst Du eine Form, wo Logik und UI kombiniert werden? Wendest Du das SOLID-Prinzip an?

[bernau]

Um mal wieder was zum Thema zu schreiben:

Ich mache das mittlerweile sehr unkonventionell. Bei mir werden neue Funktionen, Proceduren, Methoden immer am Ende der Unit angefügt. Geht schnell und ich blättere immer schnell an das Ende, um zu sehen, was ich zuletzt an der Unit gemacht habe. Ich springe sowiso immer mit Ctrl-Shift-Pfeil oben/unten immer vom Interface zur Implementation. Daher genügt mir die Sortierung im Interface-Bereich.

[Perlsau]

Ich möchte hier mal was Grundsätzliches bemerken: Wie ausführlich und wartungsfreundlich ein Programmierer eine Application entwickelt (bzw. entwickeln kann), hängt von mehreren Faktoren ab.

• Zuerst kommt natürlich die Frage: Entwickelst du hobbymäßig oder beruflich?
• Dann spielt natürlich die gesammelte Erfahrung eine große Rolle. Man kann von einem Anfänger nicht erwarten, daß er sofort alle Eventualitäten berücksichtigt.
• Arbeitest du für ein Software-Unternehmen, das umfangreiche und komplexe Anwendugnen entwickelt und pflegt (z.B. Warenwirtschaft, Praxis-Software etc.), ist es mit Sicherheit äußerst ratsam, hier eine strikte Einhaltung erprobter Entwicklungskonzepte zu fordern.
• Wer wie ich für Kleingewerbler, kleine Ladengeschäfte, Vereine und sonstige Kunden mit stark eingeschhränktem Budget entwickelt, kann nicht alle diese Forderungen einhalten, weil sonst die Entwicklungszeit zu lang und damit die Kosten zu hoch würden. Eine einfache Datenbankanwendung für z.B. einen TShirt-Druckladen, der damit seinen Bestand, seine Verkäufe, Einnahmen und Rechnungen verwalten will, entwickle ich in ein paar Tagen (rapid development), wobei meist ein Tag für die Gestaltung der Reports draufgeht. Für ein vor Jahren entwickeltes Computerkassenprogramm hab ich knapp 4 Tage benötigt. Der Kunde arbeitet noch heute zu seiner vollsten Zufriedenheit damit und hat keinen einzigen Tag bereut, bei mir diese Software in Auftrag gegeben zu haben, auch wenn er die Rechnung nur in Raten bezahlen konnte. Ein kleiner Webdesigner erhielt von mir eine umfangreiche Webvorlagenverwaltung, die ihm nach einer Entwicklungszeit von knapp zwei Wochen schon fast wieder zu teuer war.

Meine Kundschaft hat nunmal nicht das Geld, um langwierige, Entwicklungskosten im fünfstelligen Bereich zu stemmen. Ich bin mit meinen 53 Jahren froh, nach längerer Krankheit und Arbeitslosigkeit diese Marktnische gefunden zu haben. Die Programe, die ich entwickle, sind deswegen nicht schlecht oder gar Schrott, sonst würden meine Kunden nicht bereits Jahre damit arbeiten können.

[Dejan Vu]

Prinzipiell hast Du natürlich Recht: Ich würde einem kleinen Abrechnungsprogramm auch keine unglaublich ausgefeilte Architektur verpassen, wäre ja overkill.

Auf der anderen Seite wird der Code mit SOLID auch nicht viel komplexer. Man sollte sich dem Ziel, seine Programme nach diesen Prinzipien zu schreiben, aber mit jedem Projekt nähern. Unterm Strich wird man damit sogar schneller sein, als mit dem alten RAD-Prinzip, denn damit fährt man irgendwann immer gegen die Wand (spätestens bei der 10 Erweiterung oder wenn von Desktop auf Client/Server umgestellt wird). Wobei sich kleine Firmen keine ständige Weiterentwicklung leisten wollen bzw. die fehlende Komplexität der Anwendung dies auch nicht hergibt.

Kleine Anekdote aus der Möbeltischlerei: Ich mach das als Hobby und wenn ich mal eine Schwalbenschwanz-Verzinkung zweier Bretter hinbekommen habe, sind doch einige Stunden ins Land gegangen und ich habe gesägt, gefeilt, angepasst usw. Viel einfacher ist es, zwei Holzretter mit viel Ponal und 2-3 Blechwinkeln rechtwinklig zu verbinden. Sieht nicht so toll aus, hält aber Bombe.

Neulich habe ich mir ein Video angeschaut, wo jemand verdeckte Zinken mit Säge und Beitel in 10 Minuten perfekt passgenau fertig hatte: Ok, ein Meister seines Fachs. Aber eins ist klar: Es ist alles eine Frage der Übung. Keine Frage, wessen Verbindung nachhaltiger ist.

Bei der Softwareentwicklung ist es genauso: Nie aufhören, dazuzulernen, zu verbessern. Immer noch besser, noch eleganter, noch kürzer. Und nicht zu viel Zeit in Sortierung und Formatierung stecken. ;-)

[stahli]

Es ging ja eigentlich um den Wunsch, dass die IDE die Sortierung automatisch übernehmen sollte (vielleicht auch nach unterschiedlichen Optionen).
Das wäre m.E. in jedem Fall sehr hilfreich, unabhängig davon, welche Prinzipien der Entwickler sonst noch berücksichtigt. Er hätte ja dann keinen Mehraufwand.

Ach, da fällt mir noch einer ein...
http://www.delphipraxis.net/154521-p...en-editor.html
Im Beitrag #6 hatte ich schon mal angeregt, dass man im Normalfall eigentlich gar keine komplette Unit im Editor braucht, sondern nur immer eine ausgewählte Methode (weiß nicht, ob das im Bild richtig rüber kommt - da könnte sozusagen die Scrollbar im rechten Editor entfallen, weil dort nur die aktuelle Methoden bzw. deren Rumpf zu bearbeiten wäre).

EDIT: Ach so, die Registerlaschen haben im rechten Editor dann natürlich auch nichts zu suchen. Ich hätte wohl doch etwas genauer malen müssen... :oops: Zu sehen und zu bearbeiten dürfte nur der Inhalt der links angewählten Methode sein.

EDIT2: Habe nochmal neu gemalt. Zu schreiben wäre dann nur noch im gelben Bereich. Eine Gesamtsicht auf die Unit wäre dann nur noch selten erforderlich.

[Perlsau]

Zitat:

Zitat von stahli (Beitrag 1267405)

Es ging ja eigentlich um den Wunsch, dass die IDE die Sortierung automatisch übernehmen sollte (vielleicht auch nach unterschiedlichen Optionen).

Außer einem User hatte keiner Einwände.

Zitat:

Zitat von Dejan Vu (Beitrag 1267403)

Kleine Anekdote aus der Möbeltischlerei:

Was hat das jetzt mit dem Thema zu tun?

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1267407)

Außer einem User hatte keiner Einwände.

Wer denn? Also ich fand die Idee auch gut, nur nicht so wichtig. Und bei deinem *Beispiel musste ich einfach darauf hinweisen, das man auch ordentlich programmieren kann, damit sich diese Problematik nicht stellt.

Zitat:

Zitat von Perlsau (Beitrag 1267407)

Zitat:

Zitat von Dejan Vu (Beitrag 1267403)

Kleine Anekdote aus der Möbeltischlerei:

Was hat das jetzt mit dem Thema zu tun?

:roll: Denk mal drüber nach. Vielleicht kommst Du drauf. Ich bezweifle es, aber es geschehen noch Zeichen und Wunder.

So und lass es gut sein. Bitte nur noch über PN, falls Du mir persönlich etwas mitteilen willst. Danke.

Edit: (*) In einer früheren Version habe ich das Codebeispiel von Persau als Spaghetticodebezeichnet. Das ist natürlich falsch. Spaghetticode enthält verworrene Sprunganweisungen, die es in Delphi ja per se kaum bzw. nicht und im gezeigten Beispiel ellenlanger Deklarationen per definitionem nicht gibt.

[Perlsau]

Ich verbitte mir diese Beleidigungen: Das ist kein Spaghetticode!!!

Was du hier machst, ist Rufschädigung! Möchtest du nach der Verwarnung im Mai durch Mr. Spock etwa eine weitere riskieren?

[Dejan Vu]

Zitat:

Zitat von Perlsau (Beitrag 1267411)

Ich verbitte mir diese Beleidigungen: Das ist kein Spaghetticode!!!

Du hast Recht. Spaghetticode enthält verworrene Sprunganweisungen. Ich werde den Passus entsprechend korrigieren.

[Phoenix]

Boah jetzt kommt mal wieder runter. Alle beide. Das ist ja nicht mehr zum Aushalten mit Euch Beiden. :roll:

[Jumpy]

Um zum Thema zurück zu kommen: Ich hätte das auch lieber etwas anders sortiert als nur alphabetisch, hab mich aber mittlerweile damit abgefunden. In der Regel springt man doch eh mit rechte Maustaste "Deklaration suchen" (keine Ahung ob's da einen Shortcut gibt) von einer Prozedur zur nächsten.

Was ich daher schön fände wäre die Gegenteilige Funktion, sprich "Spring zurück zur letzten Codestelle die ich betrachtet habe als ich 'Deklaration suchen' benutzt habe". So ähnlich wie das im VBA-Editor ist. Oder gibt's es sowas und ich weiß es nur nicht?

[Perlsau]

Eine alphabethische Sortierung bringt meiner Erfahrung nach nicht wirklich Vorteile, denn zusammengehörender Code leitet seine "Verwandschaft" nicht aus dem Alphabet ab.

Was ich häufiger einsetze, wenn ich öfter zwischen zwei entfernten Methoden hin- und herspringen muß, sind die Positionsmarken. Sinnvoll wäre aber auch eine zusätzliche Ansicht der aktuell bearbeiteten Unit, so daß man hier nicht ständig zwischen Deklaration und Methode scrollen muß.

[Union]

Zitat:

Zitat von Jumpy (Beitrag 1267425)

In der Regel springt man doch eh mit rechte Maustaste "Deklaration suchen" (keine Ahung ob's da einen Shortcut gibt) von einer Prozedur zur nächsten.

Das geht mit Strg+G

Zitat:

Zitat von Perlsau (Beitrag 1267432)

Was ich häufiger einsetze, wenn ich öfter zwischen zwei entfernten Methoden hin- und herspringen muß, sind die Positionsmarken.

Das geht alternativ mit Alt+<Pfeiltasten links/rechts>

[Perlsau]

Strg-G zeigt die Methoden-Deklarationen leider nur alphabetisch an und nicht so, wie ich sie nach meiner Programmlogik sortiert haben möchte. Das Betätigen der Alt-Pfeil-Tastenkombination hat bei mir keinerlei Auswirkungen.