IDE-Expert gesucht zur Visualisierung von Überarbeitungen

[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ß.