Kategorien
Die 10 goldenen Regeln der Programmierung
Da ich noch auf der PHP Konferenz in Berlin bin, haben wir heute mal wieder das Glück einen Gastbeitrag präsentieren zu dürfen. Stephan Elter war kreativ und hat seine 10 goldenen Regeln der Programmierung zusammengestellt. Also wie immer Bühne frei:
Die meisten Entwickler haben sie in der einen oder anderen Form, aber bei jedem sehen sie vermutlich etwas anders aus: Die 10 goldenen Regeln der Programmierung.
1. Benutze eine IDE
Programmieren ist kein Duell im wilden Westen, es gewinnt nicht der, dessen Editor schneller gestartet ist.
Mit zunehmender Komplexität und steigenden Anforderungen ist man über jede Hilfe dankbar: Refactoring, Fehleranzeige, Codevervollständigung, Strukturansichten – erst unter Zeitdruck und jenseits von 1000 Zeilen Code fängt man an zu verstehen warum eine Entwicklungsumgebung wirklich sinnvoll ist.
2. Benutze OOP
Baue Dein Programm immer objektorientiert auf. Die Anzahl der Fehler und die kürzere Fehlersuche werden es Dir danken. Und wiederverwendbaren Code gibt es wirklich!
3. OOP ist nicht die Realität.
…und auch keine Abbildung davon. Und niemand kann behaupten, die Prozesse und Abläufe der Wirklichkeit seien auch tatsächlich von Vorteil.
Sei wenigstens so arrogant zu glauben Du bekommst es besser hin als die Realität.
4. Keine Angst vor Funktionen
Setze Klassen und Objekte immer ein wenn es Sinn macht – scheue Dich aber nicht genauso normale Funktionen zu verwenden oder Teile auch prozedural zu entwickeln wenn es Sinn macht. PHP ist nicht Smalltalk, Du darfst das.
5. Verändere keine Variablen, niemals
Im Arbeitsspeicher ist immer noch Platz für eine weitere Variable.
Wenn Du einen Wert ausgelesen oder generiert hast, behalte ihn in seiner Urform. Musst Du ihn modifizieren nimm eine neue Variable – Du weißt nie wann Du den Wert in seiner Urform noch einmal brauchst oder wie schnell Du eine Modifikation vergessen hast und dann den Fehler suchst oder den Wert an anderer Stelle wieder „zurückbauen“ musst.
6. Primitiv oder genial einfach?
Schreib Deinen Code so einfach, dass man ihn nicht nur lesen, sondern auch verstehen und vielleicht sogar warten kann.
Ein paar gesparte Zeilen, zwei oder drei Bedingungen zusammengezogen, aus drei IFs eine machen? Die nächste Fehlersuche wartet schon auf Dich – oder der Kollege, der Deinen komprimierten, unlesbaren Code warten darf.
7. Keine Baustellen offen lassen (“broken window”)
Es gibt kaum etwas schwierigeres, also tu es trotzdem: Bereinige Fehler sofort.
8. Optimiere das Design – nicht den Code
Kein Code kann mehr Zeit kosten als unnötige Datenbankabfragen, unsinnige Durchläufe oder umständliche Prozesse. Code-Optimierungen hingegen sind wie die dunkle Seite der Macht – sie sind schnell, verführerisch! Aber sie bringen nur unermessliches Leid in Form neuer Fehler oder schlechter Wartbarkeit.
9. Vertraue dem Compiler
Er ist schnell, er ist Dein Freund und er übernimmt die notwendigen Optimierungen. Was er nicht schafft, schafft ein schnellerer Prozessor oder eine Cache-Engine!
10. Kenne Deine Sprache
Du kannst nur dann auf Optimierungen wirklich verzichten, wenn Du Deine Sprache kennst und mit ihren Stärken und Schwächen umgehen kannst.
11. Keine goldenen Regeln
Niemals!
Wer etwas sich etwas ernsthafter mit dieser Thematik auseinandersetzen möchte dem seien folgende Bücher ans Herz gelegt::
„Code Craft“ von Pete Goodlife
„The Mythical Man-Month“ von F. P. Brooks, Jr.
„The Pragmatic Programmer“ von Andrew Hunt und David Thomas
Wie sehen Eure Regeln aus? Machen solche Regeln Sinn oder sind sie nur ein netter Spaß?
Danke für die Regeln. Werde versuchen meine Top10 auch bald mal zu formulieren, ich denke aber, dass sie ein wenig anders aussehen werden. Einfach anders priorisiert. Richtig sind deine auf jeden Fall auch.
Nr. 1: 🙂
Das Gute an den (verschiedenen) Regeln ist, dass sie immer wieder zum Reflektieren des eigenen Stils dienen können. Insofern bin ich gespannt auf weitere Regeln.
Meine Nr. 11: Regelmäßig eigenenen alten Code lesen und versuchen ihn wieder zu verstehen. Was völlig klar und logisch schien verschwindet leicht im Nebel des Vergessens. Deshalb den Vorsatz besser zu kommentieren immer wieder neu fassen 😉
mehr davon!
so eine art developer shame day – nur fuer goldene regeln.
und von jahr zu jahr sehen wir dann die veraenderungen.
das wird interessant.
@Eberhard: Die Nr. 11 kann ich nur bestätigen. Gerade wenn man wenig Zeit hat, ist es oft verführerisch Code ohne Dokumentation zu schreiben, nur um im Nachhinein festzustellen, dass man selbst nicht mehr weiß, was man bzwecken wollte.
Es hilft aber auch schon die Namen für Klassen, Methoden, Funktionen und Variablen besser zu wählen. Dann liest sich der Code selbst schon fast wie ein kleines Buch 😀
Ich finde, dass sich 2. & 4. sowie 8. & 10. widersprechen.
Bei 5. bin ich mir nicht sicher, wie du es meinst. Zumindest in der ausgedrückten Form ist es nicht durchführbar (Laufvariablen? :-)). Zudem würde eine Umsetzung voraussetzen, dass man Objekte nicht verändern, sondern nur noch klonen kann. Und ich bezweifle, dass der PHP-Compiler in der Lage ist, zu erkennen, welche Eigenschaften eines Objekts wiederverwendet können und somit nicht kopiert werden müssen. Insgesamt dürfte vermutlich die Zeit das Problem in PHP darstellen. (Unverändliche Variablen sind übrigens integraler Bestandteil von funktionalen Sprachen und ermöglicht leichtere Optimierungen.)
Bei 6. kann ich dir nur zum Teil zustimmen, denn es ist hilfreich, wenn der Code kurz ist. Es kommt nur darauf an, ob man die Kürze durch Tricks oder durch gute Überlegungen bewerkstelligt.
Bzgl. deines Punkts 9.: Kennst du eine Übersicht über die Optimierungen des PHP-Compilers? Würde mich brennend interessieren.
Übrigens schön, dass du in 3. OOP nicht mit der Realität gleichsetzt.
Außerhalb des Kontext von PHP würde ich Punkt 2 übrigens nicht zustimmen und bei Punkt 1 kommt es stark darauf an, wie man programmiert und welche Sprache man verwendet. In einigen Sprachen braucht man meinem Empfinden nach früher eine IDE und für andere Programmiersprachen reichen Editoren wie emacs und vi(m) lange Zeit aus.
Wenn Punkt 8 den Begriff „vorauseilende Performance-Optimierung (ohne Analyse)“ statt „Code-Optimierungen“ verwenden würde, dann hättest Du meine ungeteilte Zustimmung. Unter Code-Optimierungen gehört für mich auch Clean Code und das ist definitiv sehr hilfreich für die Wartbarkeit.
Regel 11:
Immer wenn Du versucht bist einen Kommentar im Code zu hinterlassen, um etwas genauer zu beschreien, dann benenne Deine Variablen und Methoden um, damit Sie für sich selbst sprechen und eine „Geschichte“ erzählen (dann wird der Kommentar meist überflüssig). Meistens werden Kommentare nie wieder refactored und damit „lügen“ sie mit der Zeit.
AUSNAHME: Ein Kommentar der ein komplexen RegEx erklärt ist m.E. ok, da sich kaum Einer ohne eine RegEx-Bibel aus dem Stand binnen 3 Sekunden eindenken kann, wenn die RegEx mal etwas komplexer ist.
Eine weitere goldene Regel, die sich in meiner Firma immer wieder bewährt hat (etwa 6 verschiedene Webseiten): Zentralisiere, wo du kannst! Eine Funktion über mehrere Projekte global zu machen kann einiges erleichtern. Vorallem, wenn sie rein für das Beschaffen von Daten zuständig ist und die Daten generisch zurück gibt. Findet z.B. eine Änderung an der DB statt, so muss man nur an einem Punkt Änderungen vornehmen und nicht an X Stellen, wobei man gerne mal die eine oder andere vergisst.
@Andre Moelle: Ich sehe es auch so, dass PHP eine Sprache ist, wo man keine IDE braucht, allein schon weil PHP nicht strikt genug ist, als das dort eine IDE wirklich sinnvolle Hilfen bieten könnte. Im Übrigen würde ich vim nicht in die Klasse der Editoren verbannen. Ein wirklicher Editor ist für mich sowas wie gedit. Vim kann mitunter mehr als eine IDE und solche klassischen Dinge wie Code Completion, Error Check, Deploy etc. die man von eine IDE gewohnt ist, kann Vim auch schon lange.
@sebastian: du schreibst, dass IDEs keinen Sinn machen, sagst aber danach, dass du vim als ide benutzt. Das verstehe ich nicht. Ausserdem ist php immer so strikt, wie du selbst entwickelst, da kann ich deine Meinung also absolut nicht teilen. Zusätzlich bietet dir die ide auch Dinge, die nichts mit php zu tun haben, wie zB svn, soap, xml, html, issue tracker, continuous Integration Monitoring, Ausführung der Tests …
@Sebastian: Wenn du wirklich glaubst, eine IDE kann keine sinnvolle Hilfe für PHP-Projekte sein, solltest du dir unbedingt mal PHPStorm angucken. 😉
Oh, jetzt geht der Flame War los 😀
@sebastian
bei kleinen projekten braucht man keine ide. da sind alle script sprachen gleich.
je umfangreicher das projekt wird, desto dringlicher wird gerade dann eine gute ide!
> Oh, jetzt geht der Flame War los
Das ist ja immer das Problem mit solchen „goldenen Regeln“. Auch wenn Sie mit Augenzwinkern vorgetragen werden.
PS: Zum Thema IDE: Eine IDE sollte man benutzen, wenn sie einen unterstützt. Wenn man seinen vi aus dem FF bedient und die IDE statt dessen immer im falschen Moment Code-Hints anzeigt, ungewollt Klammern vervollständigt oder man nur 1/5 der verfügbaren Features überhaupt kennt, der sollte sich nicht auf die IDE versteifen. Ich kenne durchaus Momente, wo mich die IDE wahnsinnig macht, in ihrer Behäbigkeit und Bevormundung.
Sehr schöne Zusammenfassung. Gefällt mir.
Zu 8.: Optimierung macht Sinn für Verbesserungen wie O(n2) auf O(n) oder O(n) auf O(log n) aber nicht von O(n) auf O(n-3). Das sagt eigentlich schon alles.
Und wenn, dann immer unter Verwendung der bekannten Algorithmen. Eine Kaskade durch einen Sweep ersetzen zum Beispiel. Oder den linearen Scan einer Liste durch eine höhen-balancierten Suchbaum.
Zu 4.: Zum Beispiel ein binärer Suchbaum. Es ist sinnvoll, die OOP-Theorie dahinter zu verstehen, aber man kann es auch prozedural in ~40 Zeilen mit O(log n) auf einem Array lösen.
Alternativ zu Funktionen kann man Utility-Klassen als Kapselung verwenden – Namespaces sowieso. Oder das Command-Pattern, dass sich dank __invoke() besonders elegant implementieren lässt.
@Nils: Einige der genannten Aktivitäten kann man per Kommandozeile durchführen, einige Funktionalitäten werden auch von „guten“ Editoren angeboten und über andere Dinge kann man streiten, ob man sie in einer IDE haben will. Möglicherweise ist es Geschmackssache. Vielleicht auch eine Frage, ob es sich rentiert, Zeit zu investieren, um alle der Features zum Laufen zu bringen und mit ihnen umgehen zu können. Das hängt wohl von zu vielen Faktoren an, um es zu verallgemeinern.
Dass man PHP so strikt machen kann, wie man möchte, kann ich nicht nachvollziehen. Möglicherweise verstehen wir unter „Striktheit“ etwas anderes. Ich vermute nämlich, dass Sebastian damit angesprochen hat, dass PHP schwach typisiert ist, und man somit weniger Informationen anhand statischer Codeanalyse gewinnen kann, die für eine IDE hilfreich wären. Allerdings weiß ich nicht, inwiefern das heutzutage noch auf die IDEs zutrifft, da ich z.Z. nur kleine Projekte in PHP umsetze und aus diesem Grund keine IDE benötige.
@Tom: Ich bezweifle, dass es eine OOP-Theorie zu binären Suchbäumen gibt. Sehr wohl gibt es aber eine objektorientierte Implementierung eines binären Suchbaums. Ansonsten kann ich dir beipflichten, dass man keine „Tricks“ nutzen sollte, sondern profunde Algorithmen (bzw. Ideen).
hi,
ich denke das wenn man #2 beachtet und auf sinnvolle Datenkapselung achtet, wird #5 überflüssig.
MfG
addiks
@Andre Moelle
Ich denke nicht, dass sich 2 und 4 wirklich widersprechen. 2 (OOP) ist der Idealfall, der Königsweg. Man muss aber auch bereit sein davon abzuweichen – sonst mutiert jede gut gemeinte Regel zum Selbstzweck.
Gerade OOP finde ich sehr wichtig, erlebe es aber immer wieder, dass es Fälle gibt in denen eine einzelne Funktion (nicht OO) schneller und eleganter zum Ziel führt – von dem „Königsweg OOP“ abzuweichen fällt dann manchmal auch nicht leicht
Zu 10: Es gibt in jeder Sprache „do’s and don’ts“ die man einfach kennen und berücksichtigen sollte. Eben Klassiker wie „count“ vor der Schleife. Diese Klassiker sollte man kennen.
5 bezieht sich nicht auf Laufvariablen – zumal man die nicht selbst ändert. Gemeint ist die beliebte Wiederverwendung von Variablen: Erst ist es der gesamte Pfad inklusive Dateiname, dann wird später der Pfad abgeschnitten, ein paar Zeilen weiter die Endung ersetzt und noch 200 Zeilen später wundert man sich warum das Programm nicht mehr wie erwartet reagiert oder braucht plötzlich die ursprüngliche Pfadangabe doch wieder.
Leider habe ich keine Übersicht über Optimierungen des Compilers, die so fundiert sind, dass ich sie veröffentlichen würde.
@Christian Weiss
Du kannst die Begriffe unter Punkt 8 gerne austauschen. Ich denke es geht ungefähr in die gleiche Richtung 🙂
@Stephan: Da habe ich die Hyperbel wahrscheinlich übersehen. So ergibt es natürlich mehr Sinn. In PHP halte ich OOP für das beste Abstraktionswerkzeug, aber ich kann mir vorstellen, dass es etliche Fälle gibt, in denen man prozedural genauso schnell ans Ziel kommen kann, wenn man genauso versiert in prozeduraler Programmierung wäre wie in OOP.
Der count-Klassiker gehört für mich in die Kategorie „Mikrooptimierung“, da gute Compiler in den meisten Fällen in der Lage sein sollten, zu erkennen, ob sich die Länge des Arrays nach einem Schleifendurchlauf verändern kann. Auch wenn ich nachvollziehen kann, diese Optimierung einzusetzen, und sie auch selbst einsetze, finde ich es lesbarer, wenn man es nicht machen müsste…
Das Beispiel zu 5 gefällt mir. Wenn ich dich richtig verstanden habe, sollte eine Variable einen bestimmten Zweck haben bzw. eine bestimmte Eigenschaft erfüllen, die sich während der Ausführung nicht ändert.
Danke für die Klarstellung!
>…sollte eine Variable einen bestimmten
>Zweck haben bzw. eine bestimmte Eigenschaft
>erfüllen, die sich während der Ausführung
>nicht ändert.
Ja. Das lässt sich nicht immer streng umsetzen, führt auch zu einem gewissen Overhead, der spielt aber nach meiner Erfahrung keine nennenswerte Rolle.
Das hat mir viel Zeit gespart und seitdem ich mir das angewöhnt habe treten bei der Entwicklung auch spürbar weniger Fehler/ Probleme auf.
Wer nicht refaktorisiert bleibt dumm.
@malte
bezugnehmend auf dein letztes wort solltest du dir die wortherkunft von refaktorisiert, refaktorisierung einmal auf der deutschen wikipedia ansehen 😉