Unterstriche erhöhen die Lesbarkeit

Unterstriche in Testklassennamen und Testmethodennamen optimieren unterbewusste Augenbewegungen, entlasten damit die Augen und ermöglichen schnellere Erfassung der Zusammenhänge!

Der Mensch liest nicht buchstabenweise, sondern erfasst Wortbilder oder Teile davon nach spontanen, willkürlichen Bewegungen des Auges, den Sakkaden. Das Auge springt also von einem Zielpunkt zum Nächsten. Das sind die Sakkaden. Dann findet die Fixation statt, indem das Auge sich auf ein Wort fokussiert. Nur bei den Fixationen kommt es zu einer Informationsaufnahme. Fixationen nehmen rund 90 bis 95 Prozent der Gesamtlesezeit ein. Falls das Wort nicht erkannt wird oder irgendetwas dazwischen kommt, springt es automatisch wieder dahin zurück von wo es gesprungen ist. Das sind die Regressionen.

In “KadschfunHuAugenbewegungJfdskHundOhrHeIzr” existieren keine Wortzwischenräume sodass die Zielpunkte für die Sakkaden schwer zu finden ist. Dagegen in “Kadschfun Hu Augenbewegung Jfdsk Hund Ohr HeIzr” sind die Zielpunkte schneller zu finden, weil die Wortzwischenräume automatisch Zielpunkte für die Augen bilden. Ein optimaler Wortzwischenraum unterstützt Sakkaden und den Fixationsprozess. Es finden weniger Regressionen statt.

Testklassennamen oder Testmethodennamen bestehen häufig aus mehreren Eigenworten wie beispielsweise Klassennamen und Methodennamen. Ein gutes Beispiel dafür ist “InvoiceSubModuleVerschiedeneRvgStaendeTest“. Diesen Namen kann der menschliche Leser wesentlich langsamer lesen als “InvoiceSubModule VerschiedeneRvgStaende Test“.

Das liegt daran, dass hier die Augen das Wort InvoiceSubModule in der zweiten Schreibweise viel schneller nämlich unterbewusst erkennen können und weniger suchen müssen.

Wenn die Zielpunkte schwerer zu finden sind, muss das Auge mehr suchen, also hin und herspringen. Und je öfter das Auge springen muss, um einen Text zu erfassen, desto schneller ermüdet es. Außerdem wird der Lesefluss erheblich gestört und die Lesebereitschaft nimmt ab was dazu führt, dass ähnliche Texte fälschlicherweise als gleich angesehen werden.

Quellen

“Der menschliche Lesefluss findet in drei Phasen statt: Sakkaden, Regression und Fixation. Sakkaden sind spontane Blickbewegungen, die willkürlich und zielgerichtet ausgeführt werden, um bekannte Wortbilder oder Teilstücke davon zu identifizieren. Geübte Leser erfassen Texte nicht aus einzelnen Buchstaben, sondern erkennen an der Form des Wortbildes das einzelne Wort. Es genügt oft schon, wenn die Anfangs- und Endbuchstaben sowie die Buchstabenanzahl stimmen, um ein Wort zu erkennen – auch wenn im Wortinneren die Buchstaben einmal durcheinander geraten sind.
Das Auge springt von einem Zielpunkt zum nächsten und findet mühelos zurück, falls sich Ungereimtheiten auftun. Dieses Zurückspringen wird als Regression bezeichnet. Je schwieriger ein Text zu lesen ist, desto häufiger kommt es zum Hin- und Herspringen.
Sowohl die Sakkaden als auch die Regression dienen zunächst nur dem Erfassen des Textes; ein Sinnzusammenhang wird noch nicht erkannt. Dies geschieht erst in einer Fixation genannten Ruhephase, in der das Auge für einen kurzen Moment eine Ruheposition einnimmt, um dem Gehirn das Entschlüsseln der Botschaft zu ermöglichen. Diese kurzen Momente der Fixation nehmen jedoch beim Lesen mit bis zu 90% den überwiegenden Teil der gesamten Lesezeit ein.”

Aus <http://kadekmedien.com/2010/03/03/lesbarkeit-von-texten/ >

Ein optimaler Wortzwischenraum unterstützt den Fixationsprozess und dient somit derLesbarkeit einer Schriftsatzarbeit. […]
Bis in die 1970er Jahre wurde in der typographischen Literatur, z.B. in der von Jan Tschichold (1902–1974), die Formulierung »tadelloser Ausschluß« verwendet. Heute könnte man diese Begrifflichkeit als »idealer Wortzwischenraum« bezeichnen. […]
Wortzwischenräume werden in der relativen Maßeinheit Geviertgemessen.

Aus <http://www.typolexikon.de/w/wortzwischenraum.html >

Für den optimalen Wortzwischenraum gibt es die Faustformel 1/3 eines Gevierts […]
Starke Schwankungen des Wortzwischenraums behindern den Lesefluß. Das Auge erfaßt beim Lesen nicht Buchstaben und setzt sie zu Wörtern und Sätzen zusammen, es sieht Wortgebilde als bekannte Muster. Hierbei sind Unregelmäßigkeiten äußerst hinderlich. […]
Als optimal werden 50 bis 60 Zeichen pro Zeile für längere Lesetexte angesehen. Dies bringt im Blocksatz gute Wortzwischenräume.

Aus <http://edoc.hu-berlin.de/e_rzm/18/bynum/7.pdf >

Ohne Interpunktion und Wortzwischenräume wäre das schnelle und stille Lesen undenkbar. (Vgl. Fritzsche, S. 108.) […]
Die Wortzwischenräume erleichtern das schnelle und einfache Erfassen der Wortbilder bei längeren Zeilen und bieten eine Orientierung beim Zeilensprung des Auges. (Willberg/Forssman: Lesetypografie, S. 90.)

Aus <http://bmb.htwk-leipzig.de/fileadmin/fbmedien_bmp/downloads/Abschlussarbeiten/Zweisprachige_Mikrotypografie_Amelie_Solbrig_VH-02.pdf >

Argumente gegen Unterstriche

“Coding Styles gelten für Test-Code und Produktivcode” Was sagt Uncle Bob wirklich? Qualitätsansprüche oder Namenskonventionen? Es geht um die Qualität des Tests und wenn der Methodenname aussagekräftiger ist, desto besser. Ein Name wie “FinalizeDossierTest” ist zu allgemein und beschreibt nicht, was die Test-Methode testet, sondern nur, welche Produktivcode-Methode sie aufruft. “FinalizeDossierTest” trifft für beliebig viele Testszenarien zu, die hoffentlich nicht alle in der einen Test-Methode implementiert sind.

“Es ist besser wenn für Produktivcode-Methoden und Testmethoden gleiche Konventionen gelten, Qualität und so” eben nicht! Tests haben eine ganz andere Existenzberechtigung und damit auch andere Anforderungen als Produktivcode. Zum Beispiel die Verwendung des “Test”-Postfix (eigentlich sinnlos da Test-Attribut), des TestMethodAttribute und von Microsoft.VisualStudio.TestTools.UnitTesting.Assert ist nur in Tests sinnvoll. Auch sollten Tests nicht von anderen Tests abhängig sein. All diese “Konventionen” sind nur in Tests sinnvoll. Auch wenn die Testmethode die “gleichen Konventionen” einhält wie die anderen Methoden, wird die Qualität dadurch absolut nicht besser. Eine schlechte Testmethode bleibt schlecht. Einfachheit, Verständlichkeit und Vertrauenswürdigkeit macht eine Testmethode qualitativ besser. Nach Roy Osherove: Readable, Maintainable, Trustworthy http://artofunittesting.com/definition-of-a-unit-test/

“Unterstriche kommen in den Guidelines von .NET nicht vor” gemeint ist CA1707: Identifiers should not contain underscores (http://msdn.microsoft.com/en-us/library/ms182245.aspx) und General Naming Conventions (http://msdn.microsoft.com/en-us/library/ms229045.aspx) aber da geht es um API-Design, nicht um Test-Szenarien. Das wird auch dadurch deutlich, dass Jeff Prosise in “Framework Design Guidelines” (Seite 73) die Benutzung von Unterstrichen zur Kennzeichnung von privaten Feldern legitimiert. Auch Mike Fanning (Seite 377) legitimiert Unterstriche in Membern, die nicht extern sichtbar sind, wie beispielsweise Event Handlern, die nicht öffentlich sind. Auch Roy Osherove nutzt Unterstriche nicht in Wörtern, sondern zur Abgrenzung der drei Bereiche. Worum es in der Guidelines aber explizit geht ist “readability over brevity” (Lesbarkeit vor Kürze)

“Namen der Testmethoden werden zu lang” dann wird wahrscheinlich zu viel getestet. Durch kürzere Testmethodennamen werden die Tests auch nicht besser, sondern zwingen den Programmierer den Testcode vollständig zu lesen um zu verstehen, was eigentlich getestet wird (Zeit!). Robert C. Martin sagt: “The name of a function should correspond inversely to the size of its scope.” Wenn die Methode von vielen aufrufbar ist, sollte sie einen kurzen Name haben. Methoden, die von wenigen aufgerufen werden, können längere Namen haben. Testmethoden werden nur vom Testrunner aufgerufen und haben daher einen ganz kleinen Scope. Also sind längere Namen erlaubt.

“Prägnante Namen sind besser” bei Namen der Testmethoden geht es nicht um Prägnanz sondern Aussagekraft! DossierFinalizeTest() ist zwar prägnant aber sagt nur, welche Methode getestet wird -> schlecht. Die Testmethode sollte kurz sein und der Name aussagekräftig, nicht anders rum.

Das einzige was besser wird, ist die Professionalität des Teams, die es schafft, sich an eine Regel zu halten, um der Regel Willen. Das hat mit Qualität nichts zu tun.

Kompromiss

Wenn Ihre Coding Quidelines trotzdem Unterstriche verbieten, installieren Sie sich doch einfach meine Visual Studio Extension, die die Unterstriche in Test-Methodennamen einfach wieder anzeigt: https://github.com/halllo/MethodNameRepainting

Advertisements

7 thoughts on “Unterstriche erhöhen die Lesbarkeit

  1. Meine Erfahrung ist auch, dass Unterstriche die Lesbarkeit erhöhen. Der Bedarf wird umso deutlicher, je mehr Bezeichner Tätigkeiten repräsentieren statt Gegenstände. Das ist der Fall, wenn man funktionaler programmiert, d.h. mehr auf Verhalten ausgerichtet, denn auf Daten.

    Coding Guidelines die Unterstriche konsequent verbieten gehören für mich auf den Müllhaufen der Geschichte wie die ungarische Notation. Mal vielleicht mal irgendwann sinnvoll – aber die Zeiten sind vorbei. Wir haben kein Speicherplatzproblem mehr und die Bildschirme sind breit genug bzw. die Fontgrößen einstellbar.

    Natürlich beschränke ich den Gebrauch von Unterstrichen nicht auf private Bezeichner. Und das, was weithin sichtbar ist, muss nicht kürzer benannt sein, als das lokal sichtbare. In jedem Fall geht es um den verständlichsten Bezeichner.

    Ich würde sogar im Gegenteil formulieren: je enger der Scope, desto kürzer kann der Bezeichner sein. Innerhalb einer 3-zeiligen Methode kann ich mit einem Buchstaben für einen Bezeichner auskommen, z.B. p in:

    var p = repo.Load_person(id);
    p.Name = …
    repo.Store_person(p);

    F# lässt schon Leerzeichen in Bezeichnern zu – allerdings für den Preis des Einschlusses in backticks. Eine natürlichere Schreibweise wie weiland in Elan (http://de.wikipedia.org/wiki/ELAN_(Programmiersprache)) gibts leider nirgendwo. Aber Unterstriche sind schon ok. Wenn man sich denn erlaubt, sie zu benutzen. Die Tipp- und Lesegewohnheiten sind bei den meisten noch sehr eingefahren und geprägt durch Angst, es objektiv falsch zu machen (gemessen an den lokalen Coding Guidelines oder irgendeinem Guru). Dabei kommt es auf nichts anderes an als die Leichtigkeit des Lesens. Und die kann doch jeder selbst beurteilen, oder?

    WerLieberDiesLiest als etwas mit Leerzeichen, DerSollHaltCamelCaseSchreiben. Alle anderen schreiben mit Unterstrichen.

    • Hallo Ralf,

      gut argumentiert, aber Unterstriche sind keine Leerzeichen, man kann genauso gut behaupten:
      Wer_lieber_dies_liest als etwas mit Leerzeichen, der_soll_halt_mit_Unterstrichen_schreiben. Alle Anderen schreiben PascalCase.

      • Natürlich_sind_Unterstriche_keine_Leerzeichen. Aber deshalb kann man einen Text mit Unterstrichen immerNochBesserLesenAlsEinenInCamelCase.

  2. Natürlich unterstützen Unterstriche die Lesbarkeit. Gerade auch in den Tests. Ich schrecke lediglich etwas vor dem Einsatz zurück, wenn ich einen MSTest schreiben soll, weil sie dort selten benutzt werden.

    Gar keine Frage stellt sich, sobald man MSpec einsetzt. Dort werden sie ja auch in den Ergebnisfenstern durch Leerzeichen ersetzt.

  3. Auch wenn es gut sein kann, dass Unterstriche tatsächlich die Lesbarkeit erhöhen, halte ich Deine Argumentation nicht für stichhaltig.

    Du ziehst als Argument die (fast*) richtigen Erkenntnisse aus Untersuchungen heran, die sich mit der Worterkenntnis beschäftigen. Diese Erkenntnisse über den Zusammenhang zwischen Sakkaden und der Worterkennung sind aber meines Wissens nach nur für Fließtexte erforscht und dementsprechend auch nur in dieser Domäne gültig. Einen Domänentransfer von Fließtexten auf logisch aufgebaute Abbildungen in Form von Code halte ich für sehr fragwürdig.

    Weiter beziehen sich die Erkenntnisse für Fließtexte auf Leerzeichen zwischen den Worten, und nicht auf Unterstriche – was wieder ein etwas weiter Sprung ist. Unterstriche bilden weitere (eventuell störende?) Einheiten in einem Text dar – ob dadurch wirklich das Auge auf den nächsten Wortanfang gelenkt wird und das besser als bei den Großbuchstaben bei CamelCase, ist ebenfalls nicht nachgewiesen.

    Zudem ist das eigentlich Ziel, das Du mit einer erhöhten Lesbarkeit erreichen möchtest – das schnelle Erfassen der Bedeutung von Code – nicht dadurch getan, dass Du Wörter getrennt voneinander erfassen kannst – im Gegenteil. Ein einmal erkannter Bezeichner hat im Code eine sematische Bedeutung und ist ein logisches Token. Nehmen wir an, Deine Hypothese stimmt, dann würde die Trennung der Wörter des Bezeichners beim ersten Auftauchen für die semantische Erfassung hilfreich sein. Bei allen folgenden Auftritten würde die Wörter aber nicht also zusammenhängender Bezeichner – und damit als einfaches logisches Token – erkannt werden und damit den Lesefluss sogar behindern.

    Insgesamt finde ich die Hypothese, dass die eine oder andere Schreibweise von Bezeichnern einen Vorteil gegenüber einem anderen hat interessant; aufgrund der genannten Gegenargument glaube ich aber nicht, dass man ohne weiteres eine Entscheidung für oder gegen Unterstriche treffen kann.

    Im Endeffekt sind diese Unterschiede aber sicherlich nur ein kleiner Aspekt der Lesbarkeit von Code – der Haupteffekt für eine erhöhte Lesbarkeit dürfte eher in einem gemeinsamen Coding Style und damit der Erfüllung einer gewohnten Erwartungshaltung liegen. Ob jetzt aber eine bestimmte Art der Bezeichnerwahl, von Klammersetzung vor oder nach Blöcken, Leerzeichen vor oder nach Klammern oder Operatoren, etc. besser oder schlechter ist, ist meines Wissens nach noch nicht ausreichend wissenschaftlich erforscht.

    ______
    * die Sache mit dem Lesen von Wörtern, deren Anfangs- und Endbuchstaben gleich aber die mittleren Buchstaben zerwürfelt sind, ist eine nicht tot zu bekommende Internetlegende – siehe http://www.mrc-cbu.cam.ac.uk/people/matt-davis/cmabridge/

    • Ja, Unterstriche sind keine Leerzeichen. Es geht mir auch nicht um Unterstriche per se, es geht um Wortzwischenräume. Und als Wortzwischenraum eignet sich ein Leerzeichen am Besten, dicht gefolgt vom Unterstrich. Daher denke ich schon, dass man die Feststellungen der Worterkenntnis im Bezug auf Wortzwischenräume auch auf Bezeichner übertragen kann.

      Die Erkenntnisse beziehen sich auf Fließtexte, also längere Texte. Kurze Texte (Methodennamen mit ein oder zwei Wörtern) sind auch ohne Wortzwischenräume relativ leicht zu lesen. Je länger die Texte werden (Szenarien-beschreibende Testmethodennamen), desto schwieriger ist es ohne Wortzwischenräume zu lesen.

      Wenn der Bezeichner im Code wieder vorkommt, erkennen wir immer noch ein logisches Token. Dank der Unterstriche können wir die zusammenhängenden Wörter als ein Token auch vollständig wahrnehmen. Bei Leerzeichen wäre das tatsächlich problematischer.

      Das erhöhte Lesbarkeit bei Erfüllung gewohnter Erwartungshaltung gegeben ist, sehe ich auch so. Das merke ich beim Umbrechen und Einrücken. Aber das merke ich besonders auch beim Lesen von Bezeichnern. Beim Lesen generell ist meine Erwartungshaltung, dass ich Wörter schnell erkenne und das funktioniert am Besten mit Wortzwischenräumen.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s