16. May 2012: Code schreiben, Code lesen

Denkt man an Programmieren fällt einem zunächst nur die Logik ein: Der Ablauf, den ein Programm erledigen muss um ein gewünschtes Resultat zu liefern. Hat man das erreicht stellt sich meist als nächste Frage die Effizienz: Wie kann ich das Resultat möglichst schnell oder mit möglichst wenig Ressourcen erreichen? Ein eher Grundsätzlicheres Problem stellt sich schließlich bei der Implementation: Welche Namenskonventionen verwende ich für meine Funktionieren, Variablen und Klassenbezeichnungen? Allerdings gibt es auch noch eine weitere, eher unauffällige Fragestellung: Wie kann ich mein Programm verständlich schreiben? Meistens wird hier auf eine ausgiebige Dokumentation oder sinnvolle Kommentare im Quellcode verwiesen – doch in der Realität werden diese eher spärlich umgesetzt.

Auf dieser Situation aufbauend haben Robert Green und Henry Ledgard ein paar Grundsätze über Namenskonventionen und Layout von Quellcode erstellt und in der ACM Queue veröffentlicht. Ihr Ziel war es Code so zu schreiben, dass er auch ohne Dokumentation einfach und verständlich nachzuvollziehen ist – nicht nur für andere, sondern auch für einen selbst. Wer sich jemals Jahre später durch den eigenen Spaghetticode wühlen musste um Modifikationen an einem Programm vorzunehmen, kann das sicherlich nur zu gut nachempfinden. Doch wie funktioniert dieser Ansatz? Ein Beispiel aus ihrer Veröffentlichung

char c1;
c1 = getChoice();
Switch(c1){
  case 'q': case 'Q':  quit();                break;
  case 'e': case 'E':  enterPerson(content);  break;
  case 'd': case 'D':  delPerson(content);    break;
  case 's': case 'S':  sortByName();          break;
  case 'l': case 'L':  showAll();             break;
  case 'f': case 'F':  searchByName(content); break;
  case default:        System.out.println("--Invalid Command!!\n"):
}

Wie zu sehen ist legen sie auf die Gestaltung des Codes wert – Anweisungen werden in logische Blöcke strukturiert so dargestellt, dass man durch einfaches betrachten erkennen unter welcher Bedingung welche Aktion ausgeführt wird. In ihren Grundsätzen gehen sie allerdings auch auf die Benennung (und Lesbarkeit) von Variablen, Funktionen und Klassen ein. Stets mit dem Ziel den Code für sich selbst sprechen zu lassen. Ein Artikel den sich, wie ich finde, zu lesen lohnt!

Ich persönlich gerate speziell bei den Namenskonventionen regelmäßig ins Straucheln – was zu einem guten Teil auch von meiner Trial-and-Error Programmierung herrührt: Variablen ändern durchaus öfters im Laufe der Versionen ihre Nutzung, Funktionen ihren Umfang und Klassen ihre Bestimmung (was dank Refactoring kein großes Problem mehr darstellt). Und eine wirkliche Dokumentation hat bislang noch keines meiner ohnehin eher kleineren Projekte verpasst bekommen. Daher werde ich mich bemühen bei meinen zukünftigen Projekten diese Grundsätze zu beherzigen.