Programmierstil,

Dialekt der Entwickler.

Der Programmierstil ist ein oft unterschätzter Aspekt der Softwareentwicklung. Jeder Entwickler folgt einem Programmierstil. Doch es gibt deutliche Unterschiede wie Entwickler mit dem Thema umgehen.

Zu den Grundlagen: was ist ein Programmierstil überhaupt?

Ein Programmierstil (engl. code conventions, coding conventions, coding standards) ist in der Programmierung das Erstellen von Quellcode nach bestimmten vorgegebenen Regeln. Er gilt als Teilaspekt von Softwarequalität, der insbesondere die Verständlichkeit und Wartbarkeit von Software, dies sind Kriterien für Softwarequalität gem. ISO/IEC 9126, unterstützen soll.

https://de.wikipedia.org/wiki/Programmierstil

Ein Programmierstil sind also Regeln für die Erstellung von Quellcode? Ja genau, nur dass es sich hierbei nicht um die Regeln der Grammatik der jeweiligen Programmiersprache handelt. Das bekannteste Beispiel ist die Formatierung von Quellcode, Einrückung, Zeilenlänge, Positionierung von Klammern, Benahmung von Klassen, Methoden und Variablen.

Darüber hinaus kann ein Programmierstil aber auch Regeln enthalten, die zum Ziel haben die Komplexität des Algorithmus zu reduzieren. Dabei geht es nicht zwangsläufig um die technische Komplexität, sondern auch um die Verständlichkeit. Ein prominentes Beispiel hierfür ist die McCabe Metrik, besser bekannt als zyklomatische Komplexität.

Prominente Beispiele für existierende Programmierstile sind beispielsweise PSR-1 und PSR-2 aus dem PHP Umfeld. Sowie die Code Conventions for the Java TM Programming Language von SUN/Oracle oder der Google Java Style aus dem Java Umfeld. Die Liste kann man endlos fortführen, denn es gibt mindestens genau so viele Programmierstile wie Programmiersprachen.

Ich will es damit als Antwort auf die Frage was ist ein Programmierstil belassen. Wer mehr zu dem Thema wissen will, sollte sich unter den obrigen Links auf Wikipedia umschauen.

Dialekt des Entwicklers? Wieso denn das?

Warum ich den Programmierstil als Dialekt des Entwicklers bezeichne? Nun ja, steckt doch mal nen Hamburger, nen Kölner und nen Münchener zusammen in einen Raum und lasst sie über irgendein Thema diskutieren. Das Ergebnis: Sie werden bei der Kommunikation Probleme haben. Voraussetzung für dieses Gedankenspiel ist natürlich, dass die drei einen ausgeprägten Dialekt haben und diesen auch an den Tag legen.

Bei Entwicklern ist das nicht viel anders. Um es zu verdeutlichen möchte ich einige Beispiele bzw. Programmierstile (hier in PHP) anbringen.

Der schreibfaule Hacker

<?php
class UserDao {
  public function findByLoginFromRequest(Request $r) {
    $s = $this->c->prepare('SELECT user FROM users WHERE login=?');
    $s->bindValue(1, $r->request->get('login'));
    return $s->execute() ? $s->fetch(\PDO::FETCH_ASSOC) : false;
  }
}

...wird auf jedes noch so unnötige Statement verzichtet, geschweige denn auf sprechende Variablennamen. Für ihn muss der Code so kompakt wie möglich sein und Zeit für unnötige Codezeilen hat ohnehin niemand.

Der gesittete Programmierer

<?php
class UserDao {
  public function findByLoginFromRequest(Request $req)
  {
    $login = $req->request->get('login');
    $statement = $this->db->prepare('SELECT user FROM users WHERE login=?');
    $statement->bindValue(1, $login);
    return $statement->execute() ? $statement->fetch(\PDO::FETCH_ASSOC) : false;
  }
}

...achtet schon mehr auf die Lesbarkeit. Er sucht den Mittelweg zwischen Verbosity und Kompaktheit. So hat er keine Skrupel auch mal mehrere Folgen von Methodenaufrufen in eine Zeile zu packen. Trotzdem versucht er es nicht zu übertreiben und gönnt sub-Statements auch gerne mal eine eigene Zeile.

Der Anfänger / Der Profi

<?php
class UserDao {
  public function findByLoginFromRequest(Request $request)
  {
    $sql   = 'SELECT user FROM users WHERE login=:login';
    $login = $request->request->get('login');

    $statement = $this->database->prepare($sql);
    $statement->bindValue(':login', $login);

    if ($statement->execute()) {
      return $statement->fetch(\PDO::FETCH_ASSOC);
    }

    return false;
  }
}

Der Anfänger wird möglichst jeder Befehlskette einen eigenen Raum geben. Entweder weil er (noch nicht) weiß, dass man mehrere Statements auch verschachteln kann oder aber weil er es so mal gelernt hat (zumindest ich habe es mal so in meinem Studium gelernt).

Witzigerweise sieht der Code von eingesessenen Profis oft nicht viel anders aus. Sean Hickey hat mit Die Evolution eines Software-Engineers Eindrucksvoll festgehalten was ich damit meine.

Fazit

Wie man sich eventuell denken kann, spiegeln die drei Beispiele nicht nur unterschiedliche Programmierstile wieder. Sondern auch drei Schwierigkeitsgrade der Verständlichkeit von Quellcode.

Du hast das ersten Beispiel beim ersten durchlesen direkt verstanden? Chapeau! Das gelingt bei weitem nicht jedem!

Ich hoffe es ist ein wenig klarer geworden, was der Programmierstil für Auswirkungen hat. Jeder Entwickler entwickelt sich (hoffentlich) im Laufe der Zeit weiter und damit entwickelt er auch seinen ganz eigenen Programmierstil. Einerseits ist das wünschenswert, andererseits kann es auch hinderlich sein. Gerade wenn man in einem Team - bspw. im OpenSource Umfeld - oder einer Firma mit anderen Entwicklern zusammen arbeitet, ist es wichtig dass man die gleiche Sprache bzw. den gleichen Software-Dialekt spricht. Es gibt nichts schlimmeres als Quellcode, der in Teilen in unterschiedlichen Programmierstilen entwickelt wurde, nur weil diese Teile von unterschiedlichen Entwicklern programmiert wurden.

Ich für meinen Teil bin ein Fan von extrem selbst-sprechendem Code (geworden). Bei mir sind Klassen-, Methoden- und Variablennamen oftmals sehr lang. Sogar die allseitsbekannte $i Variable ersetze ich oftmals durch ein $index oder noch besser durch $fileIndex, $userIndex, $rowIndex usw. Genau so schmeiße ich förmlich mit Variablen um mich. Dass ich mal zwei Methodenaufrufe in einander verschachtel sieht man bei mir eher selten. Wo ich das bspw. nutze sind Lambdas in Java Streams. Ansonsten leite ich Methodenergebnisse aber eigentlich immer erst in eine Variable, bevor ich diese an eine weitere Methode übergebe.

Dass ist die Art wie ich das KISS Prinzip verstehe. Quellcode muss direkt beim ersten durchlesen verstanden werden können. Und das auch von Anfängern oder Programmiersprachenfremden-Entwicklern.