2016-01-21 digital life Gute Bezeichner Ueber ihre Wichtigkeit beim Programmieren Zu oft habe ich die Worte gehoert, dass es ja nur ein Name sei, etwas um es anzusprechen; wie der Name aber laute, das sei im Prinzip egal. Den oft gebrachten Vergleich mit Kindernamen halte ich fuer unpassend, denn Personennamen muessen nicht den Sinn und die Art ihres Inhalts und seine Verwendung ausdruecken. Ich glaube, die Identifierwahl beim Programmieren gehoert zu den allerwichtigsten Einfluessen auf die Verstaendlichkeit von Code. Sie als nebensaechlich abzutun wuerdigt die Notwendigkeit, Code verstehen zu muessen, zu wenig. Warum sind Identifier wichtig? Robert C. Martin geht in seinem wertvollen Buch ``Clean Code'' gleich als Allererstes auf die Benennung ein, weil sie so wichtig sei -- da stimme ich voll zu. Leider ist seine Begruendung dieser Wichtigkeit schwach. Er fuehrt an, dass Programmierer Bezeichner staendig verwenden wuer- den und ihnen deshalb viel Beachtung schenken sollten. Damit hat er schon recht, aber das Argument ist ein schwaches. Es trifft nicht den Kern der Sache. Dieser ist folgender: Ein Computerprogramm (in einer typischen Hochsprache) besteht aus drei notwendigen Arten semantischer Information: 1) Schluesselworte und Operatoren 2) Bezeichner 3) deren Kombination und Abfolge Nur bei einer der drei Arten koennen Programmierer Verstaend- nisinformation ablegen: bei den Identifiern. Sie sind das einzige Natuerlichsprachliche in Code, das immer vorhanden ist. Diese Chance nicht bestmoeglich zu ergreifen, waere eine schlimme Ver- schwendung. Was passiert, wenn man schlechte Identifier verwendet? Damit meine ich nicht nur aussagelose Namen wie `a1', `a2', `a3', usw., die sowieso niemand mehr verwendet, sondern ich meine nicht best- moeglich treffende Bezeichner ... weil Namen ja nicht so wichtig seien. Die Folge ist, dass die in den Bezeichnern fehlende Infor- mation mittels Kommentaren nachgereicht werden muss. Damit ver- schiebt sich die Information aber aus dem Pflicht- in den Kannbereich. Ausserdem und noch schlimmer: die erklaerende Infor- mation steht nicht mehr an jeder Stelle, der der Bezeichner auf- taucht. Dies fuehrt zu einer Entkopplung, die ein Nachschlagen erfordert. Es gibt wenig Schlimmeres beim Codelesen, als staendig zur Definition von Identifiern springen zu muessen, um nachzuschauen, was sie bedeuten. Kontextwechsel verlangsamen das Codeverstaendnis massiv. Ausserdem fuehren sie zu unterschwelli- gem Frust. Das ist wie ein fremdsprachiges Buch zu lesen, bei dem man zu viele Begriffe im Woerterbuch nachschauen muss. Eine solche Geschichte kann keinen Spannungsbogen aufbauen. Die beschriebene Welt wird man nicht vor dem inneren Auge entstehen sehen. Dieses Lesen wird man ungern tun. Die staendige Ablenkung fuehrt zu unkonzentriertem Arbeiten. Unter fortgeschrittenen C-Programmieren im Unix-Umfeld hoert man oft die Aussage, dass guter Code keine Kommentare braeuchte. Dies wird einem leider meist nur arrogant an den Kopf geworfen. Entscheidend ist, was dahinter steckt: Guter Code schafft es mit- tels exzellent gewaehlter Bezeichner Informationen zu transpor- tieren, die sonst in erklaerenden Kommentaren abgelegt werden. Dadurch werden diese erklaerenden Kommentare unnoetig. Ja, guter Code hat wenig Kommentare, aber nicht aus Selbstzweck, sondern weil die gleiche Information effektiver abgelegt wurde! In der Wertigkeit von Informationsablagen stehen Identifier vor Kommentaren vor externer Dokumentation, in der gleichen Weise wie in der Speichertechnik Register vor Hauptspeicher vor Massen- speicher steht. Und analog dazu ist Registerplatz ebenso kostbar und knapp wie der Informationsplatz in Bezeichnern. (Es ist naem- lich auch wichtig sie kurz zu halten.) Man sollte also bewusst und achtsam damit umgehen. Der entscheidende Unterschied ist aber, dass schlecht genutzte Register dem Computer schaden, wohingegen schlechte Bezeichner dem programmierenden Menschen schaden. Sicher kann man die Kunst guter Bezeichner -- denn das ist sie: eine Kunst -- lange akademisch diskutieren (ich tue das durchaus gerne, zum Vergnuegen), darum geht es aber nicht. Vielmehr geht es darum, zu erkennen, dass die Wahl von Identifiern keine Neben- saechlichkeit ist, ... dass konstruktive Verbesserungsvorschlaege fuer bereits vergebene Identifier mehr als Bikeshedding sind, und ... dass diese Wahl folgenreich fuer jeden weiteren Blick in den Code ist. Namen sind nicht egal! http://marmaro.de/apov/ markus schnalke