2.7Namenskonventionen
Beim Umgang mit der Apple-Dokumentation und mit Code-Beispielen anderer iOS-Entwickler werden Sie auf einige Muster in der Benennung von Klassen, Methoden, Parametern und Eigenschaften stoßen. Apple hat in seinen Coding Guidelines for Cocoa [Anm.: https://developer.apple.com/library/ios/#documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html] umfangreiche Namenskonventionen formuliert. Tabelle 2.4 listet die wichtigsten Konventionen auf.
Element | Konvention | Beispiel |
Präfix |
Verwendung von Präfixen für Frameworks, Klassen, Protokolle, Funktionen, Konstanten und Strukturen. Keine Verwendung für Methoden und Struktur-Elemente |
NSObject, UIKit |
CamelCase |
Verwendung von CamelCase bei Komposita |
theFancyMethod: Nicht: the_fancy_method |
Methoden |
Methodennamen beginnen mit einem Kleinbuchstaben. Bei Methoden, die mit einer Abkürzung beginnen, darf die Abkürzung großgeschrieben werden. |
viewDidAppear: SHA256HashWithValue: |
Klassen |
Klassennamen und die dazugehörigen Dateien beginnen mit einem Großbuchstaben. |
ViewController, Model |
Underscore |
Die Verwendung des Underscores (_) ist nur für die Kennzeichnung von Instanzvariablen bzw. Propertys erlaubt. Apple behält sich die Verwendung des Underscores für private Methoden vor und warnt vor Namenskollisionen bei falscher Verwendung. |
_classString |
Generell sollten Sie für Bezeichner klare, aussagekräftige Namen wählen. Ein aussagekräftiger Name gibt Auskunft darüber, was seine Aufgabe ist. Zu kurze Bezeichner oder solche, die nur aus einem Buchstaben bestehen, erfüllen diese Anforderung nicht.
Nehmen Sie als Beispiel den Klassennamen des Modells im Beispielprojekt. Der Name Model ist einerseits gut, da ein Leser daraus herleiten kann, dass es sich um ein Modell handelt. Andererseits sagt er jedoch nichts über dieses konkrete Modell aus. Hier ist DroidModel geeigneter, was allerdings immer noch zu Missverständnissen führen kann. Beschreibt die Klasse vielleicht den Aufbau von Droiden? Nein, das Modell speichert Droiden, was der Klassenname DroidContainer besser beschreibt. Allerdings können Sie es hierbei auch übertreiben. Der Name DroidArray ist nicht geeigneter, da er einerseits das Implementierungsdetail verrät, dass die Klasse die Droiden in einem Array speichert, und andererseits die Objekte dieses Modells ja keine Arrays sind. DroidContainer ist also eine sehr gute Wahl für einen aussagekräftigen Bezeichner.
In vielen Programmen findet man den Namen von Action-Methoden wie beispielsweise buttonClick:. Dieser Name ist nicht nur wenig aussagekräftig, sondern auch falsch, da Buttons unter iOS nicht angeklickt, sondern berührt werden. Dass ein Button gedrückt wurde, ist beim Aufruf der entsprechenden Methode ja offensichtlich. Es ist also besser, wenn der Name beschreibt, was diese Methode macht, beispielsweise sendEMail: oder destroyAllDroids:.
Aussagekräftige Namen
Aussagekräftige Namen machen es einfacher, Ihren Code zu verstehen. Das gilt nicht nur für andere Programmierer, die Ihren Code lesen, sondern auch für Sie, wenn Sie eine Implementierungsdatei nach drei Monaten zum ersten Mal wieder öffnen. Mit aussagekräftigen Bezeichnern erhöhen Sie nicht nur die Lesbarkeit, sondern dokumentieren den Code gleichzeitig – und zwar besser, als Sie das mit langschweifigen Kommentaren erreichen können.
In der objektorientierten Programmierung modellieren Sie die Dinge aus einem bestimmten Problemgebiet, wie z. B. Warenwirtschaft, Egoshooter oder Videoschnitt. Eine gute Benennung hilft Ihnen dabei, die Aufgaben Ihrer Klassen und Methoden genauer zu formulieren. Aussagekräftige Bezeichner sind also ein Schlüssel zur objektorientierten Programmierung.
Ihre Meinung
Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.