Neue Funktionen/Methoden der RTL etc finden

[Rollo62]

Zitat von Uwe Raabe:

Kein Witz! Ich vergleiche mit jedem Release das Source-Verzeichnis der Delphi-Installation mit dem Vorgänger. Dabei fallen mir dann schon einige Konstrukte und Funktionen ein, die ich nun mit Bordmitteln erledigen kann. Bei der täglichen Arbeit weiß ich dann meistens schon: Moment, da war doch was!

Ja das mache ich auch so.
Ich kann mir aber (aus Zeitgründen) nur die gerade für mich relevanten Teile ansehen.
Wenn ich den TE richtig verstehe geht es ihm (wie mir) mehr um die "header (interfaces)",
um mal grob zu sehen wo es erwähnenswerte Unterschiede gibt, ohne sich erstmal durch alle Units zu wühlen.

Vielleicht müsste man sich ein Tool bauen, was diese Interface-Section Syntax-Tree analysieren, und vergleichen kann (falls es das nicht schon gibt).

[mkinzler]

Es wäre schön, wenn es nicht notwendig wäre, dass wir Kunden nach Änderungen suchen müssen. Aber man bekommt es ja nicht mal hin, dass die Syntaxprüfung (zeitnah) der IDE an die Änderungen angepasst wird.

[Der schöne Günther]

So früh am morgen und schon solche negativen Vibrations im Raum?

[Rollo62]

Zitat von mkinzler:

Es wäre schön, wenn es nicht notwendig wäre, dass wir Kunden nach Änderungen suchen müssen. Aber man bekommt es ja nicht mal hin, dass die Syntaxprüfung (zeitnah) der IDE an die Änderungen angepasst wird.

Aber mal ehrlich: Das wäre etwas unrealistisch sowas von EMBA zu Verlangen.
Wie oft lege ich neue Funktionen an, wie oft Refakturiere ich meinen Code ...
Jede Änderung zu Dokumentieren würde ich nicht schaffen.

Es sei denn: Das ginge automatisiert
(GIT mit Diff-Tool wäre da mein heimlicher Favorit, der könnte doch eine Change-List auswerfen)

[mkinzler]

Zitat:

Aber mal ehrlich: Das wäre etwas unrealistisch sowas von EMBA zu Verlangen.Wie oft lege ich neue Funktionen an, wie oft Refakturiere ich meinen Code ...
Jede Änderung zu Dokumentieren würde ich nicht schaffen.

Es ist aber ein Unterschied, ob es Dein eigener Code ist oder die offizielle API.
Die (Subscription-)Kosten sind ja auch nicht unerheblich.

[Rollo62]

Naja, mir ist noch lieber EMBA fixt Probleme, statt dass sie Unnötiges dokumentieren.
Wir Reden ja hier von den "kleinen" Unterschieden, nicht der "großen" Roadmap.

[mkinzler]

In Sachen Dokumentation fehlt ja leider mehr als nur ein paar "unnötigen" Details.

[Schokohase]

Zitat von Rollo62:

Naja, mir ist noch lieber EMBA fixt Probleme, statt dass sie Unnötiges dokumentieren.
Wir Reden ja hier von den "kleinen" Unterschieden, nicht der "großen" Roadmap.

Mir wäre es lieber Emba würde so arbeiten, wie man es mache sollte.

Erst mal einen Plan, was man machen möchte, mit Beschreibung was man zu erwarten hat (das nennt sich z.B. Spezifikation). Damit wäre im Prinzip auch die Dokumentation schon mal fertig.
Jetzt die Implementierung gemäß der Spezifikation/Dokumentation nebst zugehörigen Unit-Tests.

Und ehe man sich versieht ist man wesentlich produktiver weil man weniger Bugs/Probleme produziert.

Durch die stellenweise fehlende Dokumentation kann man teilweise gar nicht sagen, ob es sich wirklich um einen Bug handelt oder ob es so gewollt war.

[Rollo62]

Wir müssen aber mit dem Leben was wir haben, und da ist es realistischer selber im Code nachzusehen.

[Stevie]

Zitat von Schokohase:

Durch die stellenweise fehlende Dokumentation kann man teilweise gar nicht sagen, ob es sich wirklich um einen Bug handelt oder ob es so gewollt war.

Das ist doch gerade der Trick! Kannste Issues immer fein mit "as designed" abtun