9 Naming-Praktiken zum Abgewöhnen​

Geht’s um Naming, sollten Sie als Dev am besten so agieren, als würde Ihr Code von einem Psychopathen gewartet – der ganz genau weiß, wo Sie wohnen.Master1305 | shutterstock.com Ein betagter, aber immer noch beliebter Witz in Programmiererkreisen: Es gibt zwei schwierige Dinge bei der Programmierarbeit: Cache Invalidation, Naming und Off-by-One-Fehler. Während Erstgenanntes tatsächlich komplex ist und Letztgenanntes die Pointe darstellt, wirft die Einordnung von Naming Fragen auf. Denn Dinge in der Softwareentwicklung zu benennen, ist eigentlich simpel. Zumindest sollte es das sein. Leider legen jedoch nicht wenige Developer aus Gründen eine gewisse Aversion an den Tag, wenn es um Naming geht – und machen sich (und anderen) damit das Leben unnötig schwer. Schließlich können sinnvolle Benennungen nicht nur die kognitive Belastung bei der Codepflege erheblich reduzieren. Sie tragen auch dazu bei, Fehler zu vermeiden und Bugs zu verhindern.   In diesem Artikel beleuchten wir neun ausgesprochen schlechte Naming-Angewohnheiten, die Entwickler dringend abstellen sollten. Und geben einige Tipps, wie es besser geht.   1. Wissen voraussetzen Wissen vorauszusetzen, ist in vielen Fällen der erste Schritt in den Naming-Untergang. Sie wissen vielleicht mit Sicherheit, dass EmpNo für „Employee Number“ steht und es sich um die unique ID in der Datenbank handelt. Ein neuer Dev hält es hingegen für etwas anderes, das nichts mit den Werten in der DB zu tun hat. Wieso also nicht einfach die Dinge eindeutig beim Namen nennen? Zum Beispiel in Form von EmployeeUniqueIDInDatabase. Das ist zugegeben etwas lang, dafür sind folgenreiche Verwechslungen aber dank des klaren, deskriptiven Namings ausgeschlossen. Das Argument “zu viel Tipparbeit” greift auch an dieser Stelle nicht. Erstens ist Faulheit keine Option. Zweitens übernimmt heutzutage die IDE das Gros der Tastaturarbeit.   2. Präzision vernachlässigen Manchmal ist die Semantik einer Benennung nicht präzise genug – was im Laufe der Zeit zu “inhaltlichen Verschiebungen” führen kann. Sie könnten etwa die Methode SaveReceipt implementieren, um eine Kopie von Belegen in der Datenbank abzulegen. Nachträglich erweitern Sie die Routine dann vielleicht um Printing und verlagern den eigentlichen Speichervorgang in eine andere Methode. Und schon führt das gewählte Naming auf den Holzweg.   Die Wahrscheinlichkeit, dass es dazu kommt, sinkt dramatisch, wenn Sie von Anfang an auf eine eindeutige Benennung im Stil von SaveReceiptToTheDatabase setzen. 3. Faulenzerei vorziehen Naming ist zwar nicht diffizil, verlangt aber ein bisschen Denkarbeit – die Zeit kostet. Weil viele Devs sich diese nicht nehmen wollen (oder können), kommt es immer wieder zu Dummheiten wie Variablennamen, die aus einem einzelnen Buchstaben bestehen (einzige Ausnahme: i als Variable in einem Loop, aber selbst dann wäre Index die deutlich bessere Wahl). Stattdessen sollten Sie einer Variablen einen wirklich aussagekräftigen Namen zugestehen. Es mag etwas Zeit und Mühe kosten, lohnt sich aber. Sparen Sie sich zum Beispiel so etwas:   If (EmployeeNumber > 0) and (OrderNumber > 0) { // ... } Und gehen Sie stattdessen die Extrameile: EmployeeIsValid = EmployeeUniqueIDInDatabase > 0; ThereIsAnOrder = OrderNumber > 0; ItIsOkayToProcessTheOrder := EmployeeIsValid and ThereIsAnOrder; If ItIsOkayToProcessTheOrder { // ... } Das ist um Welten besser lesbar – und den Variablennamen ist klar zu entnehmen, wofür sie stehen. 4. Abkürzungen verfallen Faulheit ist zwar keine Option, Hektik aber ebenso wenig. Denn die führt im Regelfall nur dazu, dass eindeutiges Naming unklaren und vor allem unnötigen Abkürzungen weichen muss. Die 0,876 Sekunden, die Sie mit acctBlnc im Vergleich zu accountBalance sparen, sind wertlos, wenn es dadurch zig Stunden länger dauert, den Code zu warten. Und davon abgesehen: Um welche Account Balance geht es überhaupt? Die des Unternehmens? Die des Kunden?   Auch an dieser Stelle hilft nur: Austippen. Kürzen Sie am besten einfach gar nichts ab (von Standards wie URL und http einmal abgesehen). Das kann auch dazu beitragen, die unbegründete “Angst” vor erklärendem, klaren Naming abzustreifen. 5. Funktionen schwammig benennen Methoden sollten mit Verben benannt werden und vollständig beschreiben, was sie tun. So ist getCustomer ein guter Anfang – lässt aber Fragen offen: Woher wird der Kunde geholt? Und was genau wird dabei geholt? Die bessere Option: getCustomerInstanceFromDatabase. 6. Konsistenz über Bord werfen Wenn Sie Customer verwenden, um einen Kunden zu bezeichnen, der etwas am Point-of-Sale-System kauft, sollten Sie auch sicherstellen, dass dieses Naming überall zum Zuge kommt. Den Kunden in anderen Modulen als Client oder Buyer zu bezeichnen, führt ins Unglück. Nutzen Sie dieselben Begrifflichkeiten konsistent in Ihrem gesamten Repository. 7. Ins Negativ abdriften Insbesondere, wenn es um Booleans geht, sollten Sie auf ein positives Naming setzen, statt auf Grausamkeiten wie isNotValid oder denyAccess: if (!IsNotValid) or (!denyAccess) {   // ... } Vermeiden Sie doppelte Verneinungen in Ihrem Code unter allen Umständen. 8. Präfixe einsetzen In früheren Zeiten war die ungarische Notation sehr beliebt: Dabei wurden sämtliche Namen mit einem Präfix versehen, das definierte, um was es sich genau handelt. Das ist allerdings inzwischen aus der Mode gekommen, weil es zu komplex wurde. Ich für meinen Teil bevorzuge Namen, die aussagekräftig genug sind, um dem Maintainer zu vermitteln, was Sache ist. Beispielsweise handelt es sich bei EmployeeCount offensichtlich um eine Ganzzahl, bei FirstName um einen String. Manche Devs nutzen auch ein Buchstaben-Präfix für ihre Variablennamen, um deren Rolle in einer Methode anzugeben – etwa l für lokale Variablen und a für Methodenargumente oder Parameter. Ich bin davon nicht überzeugt. Im Gegenteil: Wenn Ihre Methoden so ausufern, dass nicht auf den ersten Blick ersichtlich ist, welche Rolle eine Variable spielt, ist Refactoring angebracht. 9. Kauderwelsch nutzen Zu vermeiden sind in Sachen Naming außerdem auch Wörter, die keine wirkliche Bedeutung aufweisen. Sehen Sie von “Naming-Junkfood” ab wie: Helper, Handler, Service, Util, Process, Info, Data, Task, Object oder Stuff. (fm) Sie wollen weitere interessante Beiträge zu diversen Themen aus der IT-Welt lesen? Unsere kostenlosen Newsletter liefern Ihnen alles, was IT-Profis wissen sollten – direkt in Ihre Inbox!