Marcel Moré zeigte, wie sich statische Code-Analyse – in anderen Programmiersprachen seit Jahrzehnten Standard – auf FileMaker übertragen lässt. Der Schlüssel liegt in einer Eigenschaft, die FileMaker längst mitbringt, die aber bisher kaum jemand für diesen Zweck genutzt hat.

Vorbild aus der Softwareentwicklung

Wer in anderen Sprachen arbeitet, kennt die eingebauten Prüfungen der IDEs oder die Testschritte einer CI-Pipeline: Der Code wird so lange durchleuchtet, bis Fehler und Warnungen abgearbeitet sind. Ein etabliertes Open-Source-Werkzeug dafür ist PMD – es unterstützt inzwischen 16 Sprachen und bringt über 400 Regelsätze mit.

Der übliche Weg dorthin ist aufwendig: Der Quelltext muss lexikalisch zerlegt, syntaktisch geprüft und in einen Abstract Syntax Tree (AST) überführt werden. Erst auf diesem Baum lassen sich Regeln formulieren – etwa zur Verschachtelungstiefe oder zur korrekten Reihenfolge von If/Else.

Der Aha-Moment: FileMaker ist schon da

Bei der Analyse mit ChatGPT kam der entscheidende Hinweis: FileMaker hat bereits mehr als die textbasierten Sprachen. FileMaker-Skripte sind tokenbasiert – hinter jedem Befehl, jeder Verzweigung, jeder Variablen steht eine eindeutige Nummer in einer definierten Struktur.

Damit entfällt der komplette Parsing-Schritt. Der AST liegt bereits vor. Und weil FM-Lab als digitaler Zwilling die Tokens ohnehin in einer Datenbank hält, reduziert sich statische Code-Analyse für FileMaker auf das Schreiben cleverer SQL-Abfragen.

Das Regelwerk in der Praxis

Aus dieser Erkenntnis entstand ein Dashboard-System mit einem ersten Satz von 68 Regeln, gegliedert nach Kategorien wie Modularisierung, Best Practices, Code-Stil, Dokumentation und fehleranfällige Konstruktionen. Beispiele:

  • Zu lange Berechnungsformeln: In der gezeigten Lösung fand sich eine Formel mit 11.000 Zeichen – ein klarer Kandidat für Refactoring.
  • Strukturprobleme: Selbstrekursive Skripte, leere If-Zweige, Loops ohne Exit Loop.
  • Doppelte Skriptnamen: Intern verwaltet FileMaker das über UUIDs. Wer Skripte aber über den Namen aufruft – per fmp-URL oder Plugin – bekommt unweigerlich Probleme.

Ebenfalls wertvoll sind die FileMaker-spezifischen Performance-Regeln, welche die AI ergänzt hat, weil die Standard-Regelsätze sie naturgemäß nicht kennen:

  • Commit Record innerhalb einer Loop
  • Export Records innerhalb einer Loop
  • Go to Layout innerhalb einer Loop
  • Go to Related Record innerhalb einer Loop

In einer großen Lösung tauchen hier zuverlässig Fundstellen auf.

Interaktiv statt Logfile

Der eigentliche Unterschied zu klassischen Analyse-Reports liegt in der Navigation. Die Ergebnisse landen nicht in einer Textdatei, sondern in interaktiven Dashboards:

  • Jeder Treffer ist anklickbar und führt direkt an die betroffene Stelle im Skript.
  • Listen lassen sich sortieren, filtern und durchsuchen.
  • Ein Health-Check-Dashboard führt eine Auswahl der Regeln in einem Rutsch aus und zeigt Warnungen und Fehler gefiltert an.

Ergänzend gibt es Spezial-Dashboards:

  • API-Auflösung: Sucht in Codeblöcken nach URLs und Schnittstellenaufrufen – generisch oder über ein eigenes Filterset, z.B. für Payment- oder Cloudflare-Schnittstellen.
  • E-Mail-Integration: Findet alle Stellen mit E-Mail-Versand und berücksichtigt dabei auch die MBS-Plugin-Varianten.
  • Custom Queries: Ein generisches Dashboard für Auswertungen wie “Top Scripts” oder “Top Tables” – etwa um zu sehen, welche Tabellen die meisten Felder haben, gefiltert nach Zahlenfeldern, berechneten oder indizierten Feldern.

Modular erweiterbar

Das Regelwerk ist bewusst offen gehalten. Wer einen eigenen Prüffall hat, formuliert eine SQL-Abfrage und baut sich daraus ein Dashboard mit direktem Sprung ins Ergebnis. Da der Objekt-Katalog von FM-Lab das gesamte Struktur-Wissen einer FileMaker Lösung bereits enthält, sind der Phantasie keine Grenzen gesetzt – per SQL lässt sich nahezu jede beliebige Anforderung als Query gegen das Objekt-Modell codieren.

Der mitgelieferte Skill /create-custom-dashboard erstellt nach vorgegebenen Regeln aus einer Anfrage in natürlicher Sprache die benötigten SQL-Queries, das Dashboard Template, Meta-Daten für die Beschreibung von Inhalt und Struktur sowie alle Sprach-Übersetzungen für die Internationalisierung. Der Skill führt den Benutzer in wenigen Schritten interaktiv durch den Prozess von einer Auswertungs-Idee bis zum fertigen Dashboard. Da das Ergebnis aus deterministischen Regeln besteht, lässt sich die Analyse anschließend ganz ohne AI Unterstützung beliebig oft und auf unterschiedliche FileMaker Lösungen anwenden.

Fazit

Die eigentliche Erkenntnis des Vortrags war nicht nur das Werkzeug, sondern die Ausgangslage: FileMaker ist mit seiner tokenbasierten Skriptform näher an moderner Code-Analyse, als man denkt. Diese Tokenform ist ein Türöffner für umfangreiche Analyse-Regeln. DuckDB als SQL-basierte Analytics-Engine liefert die Ergebnisse flexibel, schnell und skalierbar. Das flexible Dashboard-Konzept in FM-Lab bringt eine Abstraktionsebene für einfache Benutzerführung und die modulare Erweiterbarkeit mit, sowie als Option die Möglichkeit, Regel-Sets zu teilen. Denkbar wäre etwa, langjähriges FileMaker-Praxiswissen zur Performance-Optimierung in einen eigenen Regelsatz zu gießen und als ZIP-Archiv zum Download bereit zu stellen.

Weitere Infos:

FM-Lab – Static Code Analysis
https://github.com/marcel-more/fm-lab/blob/main/docs/fm-lab/Wiki/Static%20Code%20Analysis.md

PMD – An extensible cross-language static code analyzer.
https://pmd.github.io
https://docs.pmd-code.org/latest/