IDE-Expert gesucht zur Visualisierung von Überarbeitungen

[tgvoelker]

Hallo zusammen,

ich habe schon länger ein Ärgernis bei der Überarbeitung von Quellen, bei dem ich gern Eure Meinungen hören würde, und vllt. gibt es ja schon einen IDE-expert, der das implementiert.

Wenn ich Funktionen von Klassen ändere, dann muß ich die Methoden einzeln überarbeiten. Aktuell schalte ich den Editor in den Überschreiben-Modus und füge vor jeder Methode, die fertig angeschaut und überarbeitet ist (**) ein.

Muß ich mehrfach überarbeiten, dann muß ich das alles erst wieder wegmachen (gut, Suchen/Ersetzen...).

Am liebsten hätte ich es, wenn ich die Methoden markieren könnte (am Besten: globale Version für Klasse setzen, Methoden sind mit Fragezeichen markiert, wenn nicht versioniert, mit Ausrufezeichen, wenn Version kleiner und mit grünem Haken wenn Version gleich).

Gibt's sowas? Wie löst Ihr das?

[himitsu]

Ich setze mir Haltepunkte (für Kurzzeitiges bis bissl länger), aber man kann sich auch Positionsmarken setzen (in begrenztem Maße).
Auf Funktionsanfänge, aber meistens eher in der Klassendeklaration.

Ansonsten, wie wäre es mit { TODO : ... } ?
Wobei man sich bei Textdingen auch CodeTemplates einrichten könnte
und ja mit Experten (z.B. auch eigenen OTA-Erweiterungen) geht noch mehr.

[TigerLilly]

Ich verstehe das mit den Versionen je Methode nicht so recht. Für mich tut die externe Versionskontrolle samt Diff-Viewer bzw die Delphi interne Versionierung (History) alles, was ich brauche.
Und sonst: Wie himitsu vorschlägt: Code Templates sind da auch hilfreich.

[Der schöne Günther]

Zitat von tgvoelker:

Gibt's sowas? Wie löst Ihr das?

Ich würde wirklich, wirklich, in den sauren Apfel beißen und mir heutige Versionierungssysteme (Git) anschauen und deren Verwendung lernen. Die sind genau für so etwas gemacht.

Auch: Delphi markiert doch, wie jeder andere Editor auch, links die Zeilen mit einer grünen Zeile wenn sie hinzugekommen sind, und gelb, wenn sie verändert wurden.
Leider hat man da bei der neuen Minimap nicht dran gedacht, weil das ist doch eigentlich der Sinn einer solchen Map (hätte ich gedacht).

[tgvoelker]

Beispiel:
Ich habe eine Unit, in der verschiedene Klassen deklariert sind. Jetzt muß ich eine oder mehrere Klassen überarbeiten. Ich würde also die Versionsnummer der Klasse um 1 erhöhen und dann nacheinander die einzelnen nicht-abstrakten Methoden ändern bzw. prüfen, ob die Änderungen konsistent sind und wenn die konsistent sind, die Versionsnummer der Methode auf die Versionsnummer der Klasse setzen. Damit wüßte ich, welche noch nicht gemacht sind.

Bei kleineren Änderungen ist das kein Problem nachzuvollziehen, aber bei größeren Änderungen habe ich immer wieder anderes Zeug zwischendurch zu erledigen, was dann bedeutet, daß ich inmitten der Änderung 2,3 Wochen Pause habe, manchmal länger.

Diff geht dafür nicht. Todo hatte ich dafür schon. War aber aufwendig, weil ich meistens einen Haufen Todo-Einträge habe, die anderes Zeug betreffen. Haltepunkte sind ne gute Idee, die wirken ja nicht in der Deklaration. Danke @himitsu.

Und weil Günther jetzt auch noch kommt mit Git: wir haben nen eigenen Git-Server (genau: Migration von Bonobo auf Gitea steht an). Es geht darum, die konsistente zukünftige Überarbeitung ohne viel Gewese (manuelles Anlegen von ToDo-einträgen) zu unterstützen - also Arbeitsorganisation, nicht um Versionsverwaltung.

[Uwe Raabe]

Kannst du mal ein Beispiel geben, was mit Versionsnummer der Klasse und Versionsnummer der Methode gemeint ist?

[himitsu]

Man muß überall was ändern/prüfen, und möchte eine Kennzeichnug, welche Klassen/Funktionen bereits erledigt sind, bzw. andersrum, wo noch was gemacht werden muß.


Ordentlich branchen, dann geht das mit den DIFFs bestimmt auch.
Anfang mit Ende vergleichen, bzw. Branch mit Master.

[TigerLilly]

Die Versionskontrolle passt da wahrscheinlich wirklich nicht so gut. Hmm. Vielleicht eher ein Tool zum Extrahieren von Doku?

Oder Code-Folding? Und alles, was überarbeitet ist, dorthinein verschieben?

Code:

{$REGION 'Überarbeitung v1'}
...
{$ENDREGION}

[Uwe Raabe]

Ich muss gestehen, dass ich das eigentliche Problem überhaupt noch nicht verstanden habe.

[TigerLilly]

Ich hätte das so verstanden:

Code:

type
  TKlasseXY = class // überarbeitungsversion 1
    procedure A; // überarbeitungsversion 1
    procedure B; // überarbeitungsversion 1
    procedure C;
  end;

Dann weiß er, dass er an der TKlasseXY gemäß überarbeitungsversion 1 arbeiten muss und dass er A + B fertig bearbeitet hat, C aber noch nicht. Wahrscheinlich gibt es dann noch ein Dok, wo drinsteht, was bei überarbeitungsversion 1 an der Klasse zu ändern ist.

Erinnert mich auch an Requirements Management, wo man die ID einer Anforderung im Code festhält + den Status der Umsetzung dokumentiert.