create_default_configuration<\/em>).<\/p>\n <\/p>\n
Aussprechbare Bezeichner vergeben<\/strong><\/p>\nNamen sollten aussprechbar sein, vor allen, wenn man im Team arbeitet. So ist es viel einfacher, mit dem Kollegen \u00fcber\u00a0InitialReputationValueOfOwner zu <\/em>sprechen, statt sich mit\u00a0IniRepVOO <\/em>die Zunge zu verbiegen (sprecht es mal aus…), auch wenn es lang erscheint. Auch Abk\u00fcrzungen eignen sich nicht immer gut. Kann man sich beim Lesen (mit entsprechender Vorkenntnis) vielleicht noch denken, dass doB_ddmmyy<\/em> das Geburtsdatum in der Form Tag-Monat-Jahr ist, kann man mit\u00a0dateOfBirthAsDayMonthYear<\/em> genauso viel anfangen aber besser dar\u00fcber reden.
\nBeim Schreiben der langen Namen unterst\u00fctzt uns unsere IDE durch Code-Erg\u00e4nzungen, auch das ist also kein Grund f\u00fcr Abk\u00fcrzungen.<\/p>\n <\/p>\n
Substantive f\u00fcr Klassennamen<\/strong><\/p>\nVermeiden sollten wir bei Klassen allzu allgemeing\u00fcltige Namen wie Manager, Processor, Data, Info oder gar Helper. Hier ist die Gefahr besonders hoch, dass wir diese Klassen mehr Aufgaben aufb\u00fcrden, als sie haben sollten. Nach dem Single Responsibility Principle sollte eine Klasse genau eine Aufgabe haben. Eine Klasse mit dem Namen TileManager<\/em> verleitet z. B.\u00a0dazu, dass hier alle M\u00f6glichen Verwaltungsaufgaben zu einem Tile unterzubringen. Dabei w\u00e4re es sicher besser, verschiedene Aufgaben auf verschiedene Klassen aufzuteilen, etwa TileFactory<\/em>, TileComparer<\/em>, TileCollider<\/em>, TileRepository<\/em>, …
\nInsbesondere, wenn wir eins der bekannten Design Pattern umsetzen, sollten wir die Klassen auch so benennen, wie sie im Pattern verwendet werden. Das erh\u00f6ht den Wiedererkennungswert und erleichtert das Verst\u00e4ndnis f\u00fcr jeden, der das Pattern ebenfalls kennt.<\/p>\n <\/p>\n
Verben im Methodennamen verwenden<\/strong><\/p>\nMethoden erf\u00fcllen eine Aufgabe.\u00a0Aus diesem Grund soll die Aufgabe auch im Namen der Methode auftauchen, damit wir auf den ersten Blick genau wissen, was die Methode macht. So wirt mir bei der Benutzung der Methode\u00a0CreateDefaultConfiguration()<\/em> sicher sofort klar, was sie tut. W\u00fcrde die Methode nur Default()<\/em> hei\u00dfen, muss ich erst die – wahrscheinlich sowieso nicht gut gepflegte – Klassendokumentation lesen oder in den Code der Klasse selbst schauen. Beides h\u00e4lt mich auf uns kostet Zeit, ist also nicht wirtschaftlich. Diese Zeit spare ich, wenn der Name zuvor gut gew\u00e4hlt wurde.<\/p>\n <\/p>\n
Ein Wort pro Konzept<\/strong><\/p>\nBeim Finden von Namen sollte man sich angew\u00f6hnen, f\u00fcr gleiche Aufgaben auch gleiche Namen zu verwenden. Das f\u00fchrt zum einen zu einheitlichen Namen, in denen man sich besser zurecht findet – vor allem, wenn die Code-Basis w\u00e4chst. Zum anderen unterst\u00fctzt das weitere Punkte, auf die wir im Artikel Funktionen noch eingehen werden.
\nSo sollten die Getter einer Klasse immer getXX<\/em> hei\u00dfen. Haben wir eine Methode, die z. B. einen\u00a0Wert aus in einer Liste suchen soll, sollte de Methode nicht GetValue(string value)<\/em> sondern besser\u00a0\u00a0findValueByName(string name)<\/em> hei\u00dfen. Gleiches gilt, wenn die Informationen von woanders geholt werden, etwa dem Dateisystem. Die Methode getXMLFile(string filename)\u00a0 <\/em>ist dann erlaubt, wenn es eine Klassenvariable XMLFile gibt. Muss die Methode die Datei erst aus dem Dateisystem oder einem Webservice auslesen, ist fetchXMLFile(string filename)<\/em> der bessere Name. So\u00a0kann ich als Verwender der Methode auch gleich erkennen, wie gro\u00df der zu erwartende Aufwand der Methode ist (ein get<\/em> geht immer schnell und wirft keine Fehler, ein fetch<\/em> oder find<\/em> dauert ggf. und ich muss mit zu behandelnden Fehlern rechnen).<\/p>\n <\/p>\n
Dom\u00e4nenspezifische Begriffe verwenden<\/strong><\/p>\nWenn ich Code f\u00fcr bestimmte fachliche Zwecke schreibe, dann sollte ich auch die Sprache der Fachleute verwenden, f\u00fcr die die Software gedacht ist. Sagen wir mal, wir schreiben eine Software zur Verwaltung von Kochrezepten, dann sollten wir auch die\u00a0Begriffe Rezept<\/em>, Zutat<\/em> und Kochbuch<\/em> verwenden. Typischerweise schreiben wir unseren Code in englisch. Wenn die Dom\u00e4ne, in der wir uns bewegen aber nicht in englisch ist, und uns die Begriffe nicht bekannt sind, dann ist es hier durchaus erlaubt, auch die deutschen Dom\u00e4nenbegriffe zu verwenden. Auch wenn sich findRezeptByZutaten(List<Zutat> zutatenToSearch)<\/em>\u00a0ein wenig seltsam anh\u00f6rt, ist es besser, als zwanghaft englisch zu verwenden, auch wenn man mit den Worten recipe<\/em> und ingredient<\/em> nichts anfangen kann…oder benutzen wir doch eher\u00a0addition<\/em>… oder beides, je nachdem, wer es gerade programmiert?
\nHierbei ist es vor allem im Team wichtig, dass die Begriffe einheitlich verstanden und verwendet werden. Es sollte also eine Einigung im Team geben, ob deutsch oder englisch verwendet wird und welche Begriffe genau was bedeuten. Ggf. ist es hilfreich (bei umfangreichen Dom\u00e4nen vielleicht sogar notwendig) ein Glossar anzulegen.<\/p>\n <\/p>\n
M\u00f6glichst sofort den besten Namen\u00a0verwenden<\/strong><\/p>\nGute Namen zu finden ist nicht immer leicht. Es ist aber empfehlenswert, sich direkt beim Anlegen einer Klasse, Methode oder Variable kurz innezuhalten und sich Gedanken \u00fcber den Namen zu machen. Statt schnell den Klassenassistenten der IDE aufzurufen und eine Klasse mit dem Namen rrrr<\/em> anzulegen sollten wir uns \u00fcberlegen, was wir mit der Klasse anfangen m\u00f6chten und ihr einen passenden Namen geben. Statt eine Variable mal eben asdf<\/em> zu nennen, sollten wir uns \u00fcberlegen welchen Zweck die erstellte Instanz erf\u00fcllt und sie entsprechend benennen. Statt alles in einen Namespace oder ein Package zu legen, das utils<\/em> hei\u00dft, sollten wir uns \u00fcberlegen, wo jemand anders – oder wir selbst in ein paar Wochen – die Klasse suchen w\u00fcrde.<\/p>\n <\/p>\n
Zusammenfassung<\/h3>\n
Haben in unserem Code alle verwendeten Objekte, einen passenden Namen und sind in passend benannten Strukturen abgelegt, finden wir uns viel schneller zurecht und k\u00f6nnen so viel schneller – und damit wirtschaftlicher – unseren Code lesen und auch ver\u00e4ndern.<\/p>\n
Wem so gar kein guter Name einfallen will, der holt sich bei\u00a0http:\/\/www.classnamer.com\/<\/a> einfach ein wenig Inspiration. Oder noch besser: einfach den ersten Namen verwenden, der generiert wird, das verk\u00fcrzt die Zeit des Nachdenkens \u00fcber den Namen und ist damit doch wirtschaftlicher, .. \u00e4h, oder?
\n[Hinweis:<\/em> wer den letzten Satz nicht als solches erkannt haben sollte: das war ironisch gemeint, genauso wie der Classnamer an sich]<\/p>\n <\/p>\n
Viel Spa\u00df beim Anwenden,<\/p>\n
Eure Spa\u00df-Coder<\/p>\n","protected":false},"excerpt":{"rendered":"
Hallo Spa\u00df-Coder, im Artikel Basics? Kenn‘ ich doch schon! haben wir begr\u00fcndet, warum grundlegende Programmierpraktiken sinnvoll und hilfreich sind. Eine dieser Basics ist die Regel, f\u00fcr alles m\u00f6glichst aussagekr\u00e4ftige Namen zu finden. Dar\u00fcber m\u00f6chten wir im folgenden ein wenig sprechen. Aussagekr\u00e4ftige Namen Wieso steht an der Methode eigentlich nicht dran, was sie macht? Kennt ihr […]<\/p>\n","protected":false},"author":1,"featured_media":272,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[22,90],"tags":[23,18,17,29,30,28],"_links":{"self":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/258"}],"collection":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/comments?post=258"}],"version-history":[{"count":3,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/258\/revisions"}],"predecessor-version":[{"id":270,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/posts\/258\/revisions\/270"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media\/272"}],"wp:attachment":[{"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/media?parent=258"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/categories?post=258"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/invidit.de\/blog\/wp-json\/wp\/v2\/tags?post=258"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}