Add Zukunft für das Projekt
parent
7362e5d335
commit
186aab69c9
|
|
@ -0,0 +1,43 @@
|
|||
Um aus dem BMC TPL Code All-Around Plugin ein echtes, professionelles IDE-Tool zu machen, ist die zukünftige Entwicklung in drei klare Phasen unterteilt.
|
||||
|
||||
Bevor neue Features implementiert werden, fokussiert sich das Projekt zunächst auf eine saubere, wartbare Architektur.
|
||||
|
||||
🛠️ Phase 1: Architektur & Refactoring (Aufräumen)
|
||||
|
||||
Die aktuelle Codebasis muss strukturiert werden, um zukünftiges Wachstum ohne "Spaghetti-Code" zu ermöglichen.
|
||||
|
||||
[ ] Ordnerstruktur etablieren: Zerlegen der Hauptdateien in logische Module (z. B. src/providers/, src/linter/, src/utils/, src/core/).
|
||||
|
||||
[ ] Linter modularisieren: Die monolithische validateTplDocument-Funktion in eigene, testbare Teilfunktionen splitten (z. B. checkSyntax.ts, checkBlocks.ts, checkAssignments.ts).
|
||||
|
||||
[ ] Daten-Trennung: Auslagern der statischen Snippets und BMC-Funktionen in eigene Konfigurations- oder Daten-Ordner.
|
||||
|
||||
[ ] Kontext-Kategorisierung: Snippets und Hilfsfunktionen nach Gültigkeitsbereich trennen (Allgemein, Pattern, Syncmapping).
|
||||
|
||||
🧠 Phase 2: Kontextsensitive Intelligenz (UX-Verbesserung)
|
||||
|
||||
Die Autovervollständigung und Hover-Informationen sollen verstehen, wo sich der Nutzer gerade im Code befindet.
|
||||
|
||||
[ ] Kontext-Awareness: Die Autovervollständigung bietet nur noch logisch sinnvolle Snippets an (z. B. kein metadata-Vorschlag mitten in einem body-Block, kein tpl_skeleton, wenn bereits eine Modul-Definition existiert).
|
||||
|
||||
[ ] Hover-Kategorisierung: Optische Unterscheidung im Tooltip zwischen lokalen (define), extern importierten und nativen BMC-Funktionen (z. B. durch kleine Badges oder Labels im Markdown).
|
||||
|
||||
[ ] Smart Semicolons: Snippets für Funktionsaufrufe generieren das abschließende Semikolon automatisch mit, falls der Kontext dies erfordert.
|
||||
|
||||
[ ] Dynamische Trigger: Autovervollständigung bei spezifischen Blöcken wie Triggern und Bedingungen optimieren.
|
||||
|
||||
🔍 Phase 3: Deep Code Analysis (Smarter Linter)
|
||||
|
||||
Erweiterung des Linters von einem reinen Syntax-Checker zu einem intelligenten Code-Reviewer (Refactoring-Hilfen).
|
||||
|
||||
[ ] DRY-Erkennung (Don't Repeat Yourself): Ein Algorithmus, der identische oder fast identische Code-Blöcke erkennt und als "Info" markiert (Vorschlag: "Dieser Code wiederholt sich, erwäge eine define-Funktion").
|
||||
|
||||
[ ] Log-Konsolidierung: Erkennen von mehreren aufeinanderfolgenden log.*-Zeilen des gleichen Typs mit einem Quick Fix, um diese zu einer Zeile/Liste zusammenzufassen.
|
||||
|
||||
[ ] Feinmaschige Syntax-Checks:
|
||||
|
||||
[ ] Prüfung auf fehlende Kommas in Listen und Tabellen.
|
||||
|
||||
[ ] Erkennung fehlender Keywords wie then nach einem if.
|
||||
|
||||
[ ] Validierung von Operator-Kombinationen.
|
||||
Loading…
Reference in New Issue