Entwicklungskonventionen für FileMaker
Bonus: Wie dokumentiert man eigene Konventionen?
Vor einiger Zeit wurde hier auf FileMaker-Kompetenz eine Umfrage zu den Konventionen gemacht (> hier). Anschliessend an die Umfrage wurde das Thema an einem FileMaker-Stammtisch aufgenommen. Dabei stellten einige Teilnehmer Ihre Konventionen live vor. Gibt es weiteren Input zum Thema und wie kann man selbst vorgehen?
Allgemeine Konventionen für FileMaker Entwickler
Im Internet lassen sich nur begrenzte Informationen zu Entwickler Konventionen für FileMaker finden. Einzig der Artikel «Whitepaper FileMaker Entwicklerkonventionen v1.0» im FileMaker Magazin vom 2008 informiert über das «FileMaker Development Conventions Whitepaper (FDC)» von Claris (damals noch die Firma «FileMaker»).
In der Claris-Community finden sich ebenfalls keine konkreten Hinweise. In einigen Beiträgen wird auf die inoffizielle Website «FileMaker-Standards» verwiesen und die Verlinkungen auf die Dokumente zu den offiziellen FileMaker-Konventionen laufen alle ins Leere. Teilweise findet man noch Hinweise oder Links in der FileMaker-Hilfe (etwa > hier).
Gibt es also allgemeingültige und aktuelle Konventionen für FileMaker Entwickler? Nein. Es lässt sich heute nichts anderes ausfindig machen als die «FileMaker Entwicklungskonvention 1.0» in Englisch aus vergangenen Tagen. Weiter darf ich Euch die Entwickler-Richtlinien von Michael Heider zur Verfügung stellen (siehe unten).
Jeder arbeitet mit eigenen Konventionen
Die Realität bei FileMaker Entwicklern ist, dass jeder mit eigenen Konventionen arbeitet. Viele Entwickler haben aus Erfahrung oft eine ähnliche Arbeitsweise entwickelt. Das sind die «Best Practices». Details können sich unterscheiden, aber oft ist die Richtung dieselbe. Unerheblich ist es etwa, ob man einen Unterstrich oder einen Punkt für die Trennung von Tabellennamen in Beziehungen verwendet. Einigen werden sich dagegen viele darauf, dass es sinnvoll ist, Beziehungen bewusst zu benennen.
Konventionen dokumentieren
Wertvoll ist es aus Erfahrung, die eigenen Konventionen zu dokumentieren. Weitere Entwickler im Team oder allenfalls ein externer Mitarbeiter werden es verdanken. Es vereinfacht die Pflege und Weiterentwicklung jeder Lösung.
Ein paar Worte zur
- Namensgebung
- Gliederung und
- Organisation der Programm-Elemente
sind eine grosse Hilfe dabei, sich in der Lösung zurechtzufinden. Es ist eine nützliche Ergänzung der Entwicklung selbst.
Wo erstellt man am besten eine Dokumentation?
Der beste Ort für diese Dokumentation ist m. E. direkt in der FileMaker-Lösung. Als Beispiel habe ich eine kleine Datenbank erstellt, lediglich mit einer Tabelle, einem Layout und zwei Scripts. Darin lässt sich bereits vieles dokumentieren. Eine solche Lösung lässt sich problemlos in jede FileMaker Entwicklung einbinden, damit künftige Entwickler oder Mitarbeiter nützliche Informationen an einem einzigen Ort schnell zurückfinden.
In der Beispieldatei gibt es pro Thema folgende Aufgliederung:
- Titel
- Prinzip
- Beispiele
- Kommentar
- 3 Container-Felder für Dokumente oder Bilder.
Die Beispieldatei ist offen (Benutzer: admin, Passwort: admin) und lässt sich einfach den eigenen Bedürfnissen anpassen.
Beispieldatei «FMConvention», worin man die eigenen Konventionen dokumentieren kann. Die Idee ist, dass man eine solche Dokumentation in jeder eigenen Datei einbindet und dort einfach anpassen kann.
Beispieldatei für eine FileMaker-Implementation eigener Konventionen. Analog diesem Muster lässt sich in jeder eigenen Lösung beschreiben, wie man vorgegangen ist und welche Konventionen gelten – zur Hilfe für Dich selbst und jeden, der nach Dir kommt.
Erstellt und zur Verfügung gestellt von Simon Frei.
Entwicklungs-Richtlinien für FileMaker Pro Datenbanken, entwickelt von FileMakerConsulting, Michael Heider GmbH. Diese Version ist bereits älter und enthält keine Beschreibungen für neuere Elemente. Diese Datei ist nur zur Anregung gedacht.
Mit Zustimmung via Simon Frei hier veröffentlicht.
