8 Thesen um mit Stil zu programmieren - Guru 2.0
8 Thesen um mit Stil zu programmieren

8 Thesen um mit Stil zu programmieren

Programmieren mit Stil

Programmieren mit Stil

Was soll das den jetzt? Oliver hat mich in der Artikelserie Programmieren mit php und mySQL auf die Idee oder besser auf die Spur gebracht. Ausserdem grüblt man als Programmierer/Techniker immer wieder über dieses Thema nach. Gerade guter bzw. schlechter Programmierstil ist in unseren Kreisen einer der Glaubenskriege (genauso wie die ideale Entwicklungsumgebung). Da werden Meinungen als die einzig richtigen vertreten. Alles was nicht der eigenen Ansicht entspricht als falsch abgetan und so fort. Wenn Du im Internet suchst, wirst Du hunderte oder tausende Seiten, Skripten und Bücher zu diesem Thema finden und alle werden Dir die ultimative Wahrheit verkaufen.

Ich vertrete hier die gleiche Meinung wie bei der Entwicklungsumgebung: Jedem das Seine! und Alle und keiner hat Recht! Paradigmen zum guten Programmierstil kommen und gehen, genauso wie die Mode sich jedes Jahr ändert. Nach über zwei Jahrzenten in der Welt der Programmierer, kann ich eines mit Sicherheit behaupten: Es gibt ein paar Grundregeln die man einhalten muss! Und diese werde ich euch heute näherbringen, denn sie bilden eine der Säulen des Erfolgs als Programmierer und für die Anwendung. Ich mache das ganze am Beispiel der Sprache php, da es sich geradezu anbietet die oben erwähnte Artikelserie hiermit zu ergänzen. Außerdem zeige ich Dir hier nur meine eigene Arbeitsweise und will Dich nicht zu irgendetwas bekehren. Aber vielleicht ist der eine oder andere Tipp dabei, welche auch für Dich interessant ist.

In der Programmierung ist es eigentlich so, dass man sich am Anfang entweder komplett kreativ austobt. Sich nur an die Syntaxregeln hält und das Programm schreibt, ohne sich Gedanken über die Lesbarkeit oder auch das Layout zu machen. Oder man hält sich sklavisch an die Regeln des Layouts und der Lesbarkeit und wird so selbst jeder freien Denkweise beraubt. Wie immer gibt es nicht nur Schwarz und Weiß, sonder ein ziemlich intensives Grau.

1. Code Is Poetry!

Was soll ich dazu noch sagen? Nichts, ausser:

Schreibe Deinen SourceCode wie ein Gedicht und er wird Stil haben!

2. Sei Du selbst!

Dies ist vielleicht die wichtigste Regel. Viele Dinge in der Programmierung sind nämlich überhaupt nicht geregelt oder definiert, dadurch ergeben sich sehr viele Freiheiten. Du musst, in diesen Fällen, für Dich selbst einen Stil (eine Regel) finden und dieser treu bleiben. In php ist dies zum Beispiel der Blockoperator, die geschwungen Klammern. Obwohl es noch genug andere Punkte gibt, welche in verschiedenen Varianten geschrieben werden können. Ich zeige Dir hier zwei Beispiele:

Variante A

Variante B

Du wirst sofort Verfechter für beide Varianten finden. Syntaktisch sind für php die beiden Schreibweisen gleichwertig. Ich persönlich bevorzuge einfach die Variante A, da sie für mich besser lesbar ist. Aber diese Art der Schreibweise des Blockoperators ziehe ich konsequent in allen meinen Anwendungen durch. Wenn jetzt jemand anders mein Programm liest, erkennt er diese Schreibweise und stellt sich darauf in. Würde ich dauern zwischen den Varianten wechseln, erkennt der Leser ist nicht intuitiv und muss jedesmal suchen, wo ein Codeblock beginnt und wo er endet.

Genauso ist es bei der Schreibweise von Operatoren. Auch diese habe ich in den beiden Beispiel oben verändert. Für php ist es komplett egal ob Du Leerzeichen machst oder nicht. Auch hier verwende ich in all meinen Programmen die Variante A. Der Grund ist für mich wieder die bessere Lesbarkeit.

Suche Dir auch eine Namenskonvention für die Benennung von Konstanten, Variablen und Funktionen aus. Ich persönlich bevorzuge CamelCase-Notation [EN].

Wenn Du jemals in die Versuchung kommst ein “fremdes” Programm, also Code von anderen Programmierern zu verändern oder anzupassen, dann verwende den vorgefundenen Stil. Dies ist einfach der Respekt vor dem Anderen und zusätzlich bleibt der Code lesbar.

3. Blöcke sind schön!

Es ist wirklich so! Schau Dir nochmal die Beispiele oben an. Sie sind durch die Einrückung um vier Zeichen einfach lesbarer. Und genau das solltest Du machen: Rücke abhängige Zeilen immer um je 4 Leerzeichen ein. Nimm keinen Tabulator, denn das kann auf den verschiedensten Systemen zu Problemen führen. Für die Einrückung gebe ich Dir wieder ein Beispiel, wie es gut aussieht und auch lesbar bleibt.

 

Du gibst mir sicher recht, dass der Beispielcode einfach zu lesen ist. Denn Du siehst auf einen Blick was zusammen gehört.

Dazu gehört auch der bewusste Einsatz von Blockoperatoren. Natürlich gibt es die Gruppe, welche Code nur schön finden, wenn er möglichst kurz ist. Aber schöner Code ist einfach lesbar und verständlich.

Variante A

Variante B

Schau und urteile selbst: Ist die Variante A nicht klarer und lesbarer? Sicher gibst Du mir recht, oder? Danke! Auch ich verwende diese Variante um meinen Code besser zu gestalten.

4. 80 Zeichen sind genug!

Auch hier gibt es alle Typen von Programmierern. Jene die ultrakurze Zeilen schreiben und jende die elendslange Zeilen programmieren und natürlich alle Schattierungen dazwischen. Ich habe die Erfahrung gemacht, wenn man sich auf 70 bis 80 Zeichen pro Zeile beschränkt, ist es ganz praktisch. Erstens passt alles auf eine Bildschirmbreite, zweitens läßt sich so formatierter Sourcecode einfach auf eine DIN-A4 Seite ausdrucken (ohne störende Umbrüche).

5. Das Leerzeichen ist Freund und Feind!

Wenn Du Leerzeichen bewusst einsetzt können sie Dir wirklich helfen. Versuchst Du aber einfach nur den Code reinzutippen und machst Dir über Leerzeichen Gedanken wird es bald nicht mehr lesbar sein. Mache vor einem öffnenden Blockoperator ein Leerzeichen, dass hilft Dir bei der Unterscheidung der Klammern.

Auch beim Zuweisungsoperator sind Leerzeichen willkommen. Schau Dir einfach die Varianten an und Du wirst wieder die Variante A (mein Liebling) lesbarer finden.

Variante A

Variante B

Es kann aber auch Dein Feind sein:

Sobald Du Leerzeichen zwischen dem Funktionsnamen und den Übergabeparametern machst, sieht es so aus, als ob die beiden nicht mehr zusammengehören.

6. Optionen kommen zum Schluss!

Bei Funktionen kann man ja eine Liste der Übergabeparameter definieren. Beide gezeigten Varianten sind syntaktisch wieder richtig, aber welche ist lesbarer?

Variante A

Variante B

Du wirst sicher sagen: Variante A. Auch ich bevorzuge diese Art der Reihenfolge: Alle Argumente mit einem Standardwert werden am Ende aufgereiht. Du siehst, ich habe auch die Leerzeichen weggelassen, da dadurch die Zusammengehörigkeit des Tupels (Parameter-Werte-Paar) besser zum Ausdruck kommt. Wieso reiht man diese Art der Parameter jetzt an das Ende der Liste? Viele Programmiersprachen kennen sogenannte optionale Parameter und können diese auch explizit definieren, nur php nicht. In dieser Sprache ist prinzipiell keines der Argumente einer Funktion ein Pflichtfeld. Es hängt nur von Dir, als Programmierer ab, ob die Funktion mit einem Fehler reagiert oder nicht. Aber wenn Du Argumente mit Standardwerten vorbelegst, kannst Du sie beim Aufruf der Funktion weglassen und trotzdem kannst Du den Basiswert innerhalb der Funktion verwenden.

7. Was gehört wohin?

Wir programmieren ja so, dass wir Funktionen die wir öfters brauchen in eigene Dateien auslagern. Genauso hat jede Datei selbst definierte Variablen und Funktionen. Gewöhne es Dir an, diese immer in derselben Abfolge in die Datei zu schreiben. Ich mache es so, dass ich nach dem Kommentarblock folgendes mache.

  1. externe Dateien, welche eingebunden werden
  2. Definition der Konstanten
  3. Definition der Variablen
  4. Sourcecode ausserhalb von Funktionen
  5. globale Funktionen
  6. Hilfsfunktionen für Punkt 5

8. Kein Programm ohne Kommentar!

Wenn Du noch nicht so viel porgrammiert hast, wirst Du dir denken, was soll den das? Ich verstehe doch was ich programmiere und brauche es nicht mehr zu erklären! Ja, jetzt verstehst Du es, aber wie schaut es in zwei Wochen, zwei Monaten oder einem Jahr aus? Wirst Du dann noch immer alles Routinen und Befehlssequenzen kennen oder musst Du dich wieder “hineindenken”? Wahrscheinlich ist es das zweitere und das wird Dich mit der Zeit ziemlich nerven.

Wenn Du mit einem Tool wie phpDocumentor [EN] arbeitest bist Du so oder so gezwungen eine gewisse Struktur Deiner Kommentare einzuhalten. Falls nicht solltest Du dir ein ähnliches oder für Dich angepasstes Schema überlegen und konsequent anwenden. Wenn Du viel programmierst oder vorhast zum Programmierer zu werden, wirst Du über kurz oder lang ein Tool einsetzen. Warum also nicht gleich? Hier ein Beispiel für einen langen Kopfkommentar einer Datei (In der oben erwähnten Artikelserie verwende ich, aus praktischen Gründen, immer eine Kurzversion).

In Punkt 3 hast Du vielleicht bemerkt, dass ich beim schliessenden Blockoperator auch einen Kommentar angefügt habe. Es ist einfach praktisch, denn man sieht sofort zu welcher öffnenden Klammer diese einsame, allein dastehende schliessende Klammer gehört. Gerade bei langen Blöcken – welche über eine Bildschirmseite gehen – sparst Du dir mit dieser Praxis viel hin und her scrollen im Sourcecode.

Auch jede Funktion, jede Klasse und so fort soll (muss) dokumentiert werden. Ich verwende dazu auch das Schema von phpDocumentor [EN]. Im unten gezeigten Beispiel zeige ich wie es wirklich aussehen kann. Ich verwende wieder nicht alles was phpDoc anbietet, sondern das was für mich praktikabel und sinnvoll ist.

Falls Du keine klingenden Variablennamen verwenden willst oder kannst, dann dokumentiere sie gleich inder selben Zeile. Dann brauchst Du später nicht suchen wo Du sie dokumentiert hast, oder falls Du es übersehen hast (was ja nie passiert) aus dem Code die Bedeutung herauslesen.

Fazit

Was denkst Du darüber? Schreibe mir doch einen Kommentar mit Deiner Meinung. Aber denke daran: Ich predige keine unumstösslichen Gesetze und auch nicht der Weisheit letzter Schluss, sondern Erfahrungen aus mehr als zwei Jahrzehnten Programmiererfahrung. Ich habe über die Jahre bemerkt, dass jeder Programmierer seinen eigenen Stil entwickelt, wie ein Künstler. Man kann Sourcecode – wie in Punkt 1 festgestellt – wie Poesie lesen. Und man spürt und sieht wirklich den Menschen dahinter!

Es wurden 6 Kommentare zu diesem Beitrag geschrieben.

  • Oliver Klee

    Bis auf den camelCase für Variablen stimme ich dir zu.


    so würde ich das machen. Es gibt sogar noch eine ganz andere unart Variablen zu schreiben:


    “i” und “s” geben an welchem Typ die Variable entspricht. Meiner Meinung nach keine besonders gute Idee, weil man sonst auf die Idee kommen könnte, sie einfach ohne “typprüfung” weiter zu verwenden. Klingt vielleicht weit hergeholt, aber schon mehr als einmal source in der Hand gehabt, in der mir ein Integer wert als String verkauft wurde, was erst einmal zu unerklärlichen Fehlern führte.
    @Kommentare: phpDoc ist klasse, da spricht man mit Entwicklern auf der ganzen Welt die selbe “Sprache”. Gute Beispiele für den vorbildlichen Einsatz von Kommentaren mit phpDoc sind wordpress source code zu finden.
    Eine IDE oder auch Editor mit entsprechendem plugin, unterstützt einen beim Schreiben von phpDoc Kommentaren (pdt tut das).
    @Leerzeichen und tabs: Viele ide’s und editoren kann man so einstellen, das wenn man die tabulator-taste drückt, dieser automatisch vier leerzeichen “eingibt”. Dann muss man die Leertaste nicht so quälen.
    Wer sich natürlich die Arbeit machen möchte, kann auch in der eigenen ide einstellen wie man als shortcut den den quelltext formatiert. Einmal ein wenig konfigurationsarbeit und schon wird der komplette source formatiert *g*.
    @Code is Poetry: Das hab ich mir auf meinen iPod gravieren lassen 😉

    • Guru 2.0 Autor

      Mit dem Editor und den plugIns gebe ich Dir vollkommen recht. Daher verwende ich auch Eclipse. Diese IDE macht das alles und zusätzlich kann man phpDoc auch noch einbauen.

  • Oliver Klee

    Ok die Elemente wurden rausgefiltert *grml*. Pöses Kommentarscript.
    Sry für den Doppelpost! War etwas zu enthusiastisch, beim Schreiben des Kommentars.
    Das hier unten sollte eigentlich da angezeigt werden wo jetzt weise Freiräume sind:

    $kunden_nr = 20314;
    2.$vorname = "Guru";
    3.$nachname = "2.0";
    4.$web = "https://www.guru-20.info";
    5.$mehr_info = "Ich liebe diesen Blog!";

    $iZahl = 5;
    $sString = "Hallo Welt";

  • Oliver Klee

    Ja mein ich ja, wollte nur nicht wieder so offensichtlich Werbung für eclipse machen. Danke 🙂

  • Thomas

    Eine “Regel” würd ich für PHP noch hinzufügen: Funktionen immer in Klassen kapseln, selbst wenn eine Klasse nur statische Funktionen hat. Dadurch werden klare Namespaces geschaffen und die Wiederverwendbarkeit erhöht sich unheimlich.
    Zum Thema IDE: hab mir nach Jahren mit PHPEclipse und PDT angewöhnt mit Netbeans für PHP zu arbeiten. Funktioniert irgendwie besser und ist irgendwie schöner damit zu coden, keine Ahnung wieso. Probiert es mal aus…
    PHPDoc ist natürlich Pflicht und jede moderne IDE unterstützt es ja…

  • Felix

    Natürlich gibts da immer wieder Streit. Ich bevorzuge
    if(bedingung)
    {
    anweisungen;
    }

    Bei einer einzigen Anweisung lass ich die Klammern weg. nach einem if, switch,for,etc. oder einem Funktionsnamen kommt kein Leerzeichen. Und ich benutze den Tabulator. Ich hatte damit noch nie Probleme, wenn er richtig und durchgängig benutzt wurde. Außerdem kann bei den meisten Editoren die Tabulatorbreite auf eine persönliche Vorliebe gesetzt werden. Ich hab 2 eingestellt. Um die Operatoren herum verteile ich aber auch großzügig Leerzeichen.

Blogheim.at Logo
Diese Website verwendet Cookies - nähere Informationen dazu finden Sie in unserer „Datenschutzerklärung“. Klicken Sie auf „Ich stimme zu“, um Cookies zu akzeptieren und unsere Webseite zu besuchen, oder klicken Sie auf „Cookie-Einstellungen“, um Ihre Cookies selbst zu verwalten.