Wie ein neues ESLint-Plugin für Klarheit in unseren Quelltexten sorgt
Die meisten unserer Projekte werden von mehreren Developers umgesetzt. Sie bringen unterschiedliche Erfahrungen aber auch Vorlieben ein, etwa zur Benennung von Variablen und Funktionen. Damit in den Quelltexten trotzdem eine gemeinsame Sprache gesprochen wird, haben wir innerhalb der Firma und ihrer Projekte Namenskonventionen festgelegt. Sie sollen vermeiden, dass eine Funktion zum Authentifizieren einmal als login() geschrieben wird, ein anderes Mal jedoch als logIn() oder log_in().
Das Einhalten der festgelegten Namenskonventionen lässt sich auch gut über Tools zur statischen Codeanalyse, sogenannte Linter, automatisch prüfen und durchsetzen. Das für die Programmiersprache JavaScript weltweit am meisten genutzte ESLint bietet hierfür von Haus aus die Regel id-denylist an. Sie erlaubt es, die Verwendung einzelner Begriffe wie logIn, LogIn und log_in in Quelltexten generell zu unterbinden, sodass nur noch login als einheitliche Schreibweise möglich ist.
Dieser Ansatz stößt jedoch schnell an seine Grenzen: einerseits wird die Liste der zu vermeidenden Begriffe aufgrund von unterschiedlichen Groß- und Kleinschreibungen schnell sehr lang, andererseits sollen manche Varianten in bestimmten Kontexten dann doch erlaubt sein. Was nämlich, wenn der Begriff Teil eines längeren ist, wie bspw. logIntoDashboard() oder log_in_file()?
Um diese Nachteile zu beheben, haben wir die ESLint-Regel id-denylist so angepasst, dass nicht nur feste Bezeichner als unerlaubt markiert werden können, sondern auch Muster von Zeichenketten. Über sogenannte reguläre Ausdrücke kann dann auch Bezug genommen werden auf den Kontext, in dem diese Muster auftauchen.
Das entstandene ESLint-Plugin mit dem etwas sperrigen Namen eslint-plugin-id-denylist-regexp (wo wir wieder bei der Überschrift dieses Artikels wären) haben wir unter der freien MIT-Lizenz und als Open Source auf GitHub und npmjs.org veröffentlicht. Es kann so auch leicht von anderen Developers und Firmen als Ersatz für die ESLint-eigene, zu starre Regel id-denylist genutzt werden. Die Festlegung auf die einheitliche Schreibweise login ist dann nur noch folgender Einzeiler:
/* eslint susiandjames/id-denylist: [„error“, „/(^|[^a-z0-9])[Ll]og(I|_i)n$/“] */
