Brummel/MycLib
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

Ki Gem

Browse Source
This commit is contained in:
Michael Schimmel
2025-11-23 14:44:28 +01:00
parent a052dfb20f
commit 30933072a4
1 changed files with 13 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files
KI/gemini.md
+13 -10
View File
@@ -79,19 +79,25 @@
* RECORDs, die einen Initialize-Operator haben, sind Managed Records. Sie benötigen also kein explizites Create. * RECORDs, die einen Initialize-Operator haben, sind Managed Records. Sie benötigen also kein explizites Create.
* Vorwärtsdeklarationen von Records werden in Delphi nicht unterstützt. Die Lösung dafür ist, das benutzende Element im Scope des Records zu definieren. * Vorwärtsdeklarationen von Records werden in Delphi nicht unterstützt. Die Lösung dafür ist, das benutzende Element im Scope des Records zu definieren.
# In Unit-Tests # Unit-Tests
* Verwende nur statische Strings für Log-Einträge und Asserts. Keine Format(), ToString usw. (Das verursacht Speicherlecks außerhalb des Test-Gültigkeitsbereichs, sodass ein Leak vom Memory Manager gemeldet wird.) * Unit-Tests basieren auf DUnitX.
* Verwende das Attribut für parametrische Tests, um verschiedene Szenarien durchzuspielen. Z. B. [TestCase('TestName', 'Parameter1,Parameter2,...')] * Verwende in Tests nur statische Strings für Log-Einträge und Asserts. Kein Format(), ToString usw. (Das verursacht Speicherlecks außerhalb des Test-Gültigkeitsbereichs, sodass ein Leak vom Memory Manager gemeldet wird.)
* Verwende möglichst Assert.AreEqual<T>() anstelle von Assert.AreEqual().
* Nutze das TestCase-Attribut um Tests zu parametrisieren ausgiebig. Z. B. [TestCase('TestName', 'Parameter1,Parameter2,...')]
* Neue Test-Units haben den Namen "Test.[unit].[what].pas", wobei [unit] der volle Name der zu testenden Unit ist und [what] ein optionales Wort, falls nur ein spezieller Aspekt der Unit getestet werden soll.
# Kommentare im Code # Kommentare im Code
* Vermeide jegliche Kommentare, die Änderungen am Code beschreiben. Z.B. `// hier wurde was geändert`. Das mag ich gar nicht.
* Kommentare sind immer englisch. * Kommentare sind immer englisch.
* Vermeide jegliche Kommentare, die Änderungen am Code beschreiben. Z.B. "// changed", "// added", "// removed".
* Benutze keine HTML-Tags (`<summary>`, etc.)! * Benutze keine HTML-Tags (`<summary>`, etc.)!
* Benutze `//` oder `(* *)` und fasse dich extrem kurz. Meistens genügen Einzeiler vor den Deklarationen. * Benutze `//` oder `(* *)` und fasse dich extrem kurz. Meistens genügen Einzeiler vor den Deklarationen.
@@ -120,11 +126,8 @@
- Formatiere in Markdown. Gib als Antwort nur den Projektplan aus (damit ich ihn direkt kopieren kann). - Formatiere in Markdown. Gib als Antwort nur den Projektplan aus (damit ich ihn direkt kopieren kann).
- Füge Datum und Uhrzeit hinzu. - Füge Datum und Uhrzeit hinzu.
- Gliedere in der Reihenfolge: Motivation - Ziel - Ergebnis - Gliedere in der Reihenfolge: Motivation - Ziel - Ergebnis - Nächster Schritt
- Fass dich kurz
* Füge eine kurze Todo-Liste an, welche die nächsten Schritte skizziert.
# Interface helper # Interface helper
**Interface helper** sind ein Konzept, dass *nicht* explizit in Delphi/Pascal verankert ist. Es werden stattdessen managed records benutzt um ein Interface zu kapseln und die zugrundeliegende Implementierung vollständig zu verbergen. **Interface helper** sind ein Konzept, dass *nicht* explizit in Delphi/Pascal verankert ist. Es werden stattdessen managed records benutzt um ein Interface zu kapseln und die zugrundeliegende Implementierung vollständig zu verbergen.