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

Delphi-Quellcode:

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

Zitat von tgvoelker (Beitrag 1543071)

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.

[tgvoelker]

Zitat:

Zitat von TigerLilly (Beitrag 1543109)

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.

Exakt. Gutes Beispiel ist, daß eine Klasse threadsafe gemacht werden soll. da muß ich dann alle Methoden prüfen, ob das Syncobjekt verwendet wird.

Haltepunkte an den Methoden überleben Speichern und Neuladen nicht, geht also nicht.

Als Kommentar ranschreiben ginge, kollidiert aber mit anderen Kommentaren. Das einfachste war bisher (**) im Überschreiben-Modus vorn ranzuschreiben.

Schätze mal, da gibt's bisher nix.

[Sherlock]

So sehr es mir Bauchschmerzen macht, das zu empfehlen, aber die Bookmarks von Embarcadero (Parnassus), sollten da helfen. https://docwiki.embarcadero.com/RADS...itor_Bookmarks

Aber Achtung! Mit jedem IDE Update geht bei Parnassus was kaputt, wenn man sie vorher nicht deinstalliert.

[TigerLilly]

Ich würd mir mit Makros was basteln. MMX hat einen 1-line-comment, den man ev. auch dafür verwenden könnte. Code-Templates hatten wir ja schon.

Ich weiß ja nicht, was du nachgelagert alles brauchst, aber beim Compilieren kannst du dir ein XML erzeugen lassen und aus dem alles mögliche extrahieren und anzeigen.

[Uwe Raabe]

Ich würde auch nicht einen Kommentar wie (**) verwenden, sondern die Versionsnummer dort angeben. Dann muss man das nicht bei der nächsten Version entfernen sondern kann einfach die Versionsnummer anpassen.

Mit dem bereits erwähnten MMX One-Liner würde das dann so aussehen:

Delphi-Quellcode:

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

Mit dem sichtbaren Documentation-Pane von MMX ist der One-Liner auch bei der Bearbeitung der Implementierung sichtbar und lässt sich auch einfach ändern ohne wieder zum Interface zu wechseln.

[TigerLilly]

Ich würde ja so ein Tool dazu nutzen:
https://devjetsoftware.com/products/...ation-insight/

[TurboMagic]

Würde man XMLDOC für die Kommentare nutzen, könnte man den entsprechenden Kommentar sehen,
wenn man weiter unten im Code über einen Aufruf dieser mit der Maus fährt. Beispiel:

Delphi-Quellcode:

type
  TMyClass = class
  public
    /// <summary>
    ///  Version 1
    /// </summary>
    procedure DoIt1;
  end;

[himitsu]

Wobei in die Beschreibung eher war Anders reingehört. (die kann man sich ja nun von der AI generieren lassen :freak:)

Dann doch eher so?

Delphi-Quellcode:

/// <summary> Diese Funktion macht irgendwas, auch wenn niemand weiß was. </summary>
/// <remarks> Version 1 </remarks>
procedure DoIt1;

... oder vielleicht doch?
/// <summary> Version 1: Diese Funktion macht irgendwas, auch wenn niemand weiß was. </summary>
procedure DoIt2;

[vnvjan]

Warum nicht zusätzlich noch:

Delphi-Quellcode:

{$region 'Version XYZ' 
...
$endregion}

zum Kommentieren benutzen. So bleibt der Code sauberer und man kann sich Teile nur im Editor anzeigen lassen, die man wirklich braucht.

[Uwe Raabe]

Das mit der Region wäre in der Tat ein alternativer Ansatz, wenn man jeweils die bereits bearbeiteten Methoden in die Region verschiebt. In diesem Beispiel stehen die noch zu bearbeitenden Methoden dann immer am Anfang der Deklaration:

Delphi-Quellcode:

type
  TKlasseXY = class
    procedure C;
{$region 'V1' }
    procedure A;
    procedure B;
{$endregion}
  end;

[tgvoelker]

DocInsight habe ich. Für Doku gut, für Methodenversionierung eher nicht.

In Kommentar reinschreiben war mein erster Ansatz - sehe ich halt nicht auf den ersten Blick was ich noch machen muß.

[tgvoelker]

Mal ein kleines Update: einen Experten für die IDE habe ich nicht gefunden, aber da ich sowieso unseren Git-Server umstellen mußte, habe ich OpenProject aufgesetzt und nutze dort die Managed Repositories. Das geht (mit LDAP-Auth) OnPrem perfekt.