45 Tipps für sauberen Quellcode

Ich sehe immer wieder Quellcode, der total unübersichtlich ist. Es ist immer schwierig diesen Quellcode später wieder zu verstehen. Außerdem kann man leicht etwas zerstören oder auch „nur“ verlangsamen. Da ich zu meinen Anfängen als Entwickler (so mit 14-15 oder so^^) selber nicht immer ganz sauber programmiert habe, ist es schwer später die jeweiligen Sachen zu überarbeiten. Und aus diesem Grund habe ich diese Liste veröffentlicht, damit ihr euren Code sauber haltet! Ihr könnt ihn zum Beispiel auch euren Kollegen geben, so dass ihr auch Vorteile habt, wenn ihr deren Code erweitert.

Los geht’s:

1. Kommentiere keinen Quellcode aus. Lösche ihn am besten sofort. Eine Versionverwaltung wird den alten Code immer parat haben.
2. Kein Codeblock darf doppelt vorkommen! Am besten ist es sogar, wenn keine Codezeile doppelt vorkommt, was sich allerdings nicht immer vermeiden lässt.
3. Benutze keine Konstruktoren, denn so kann man in einigen Sprachen das Objekt zum Beispiel nicht serialisieren. Außerdem weiß man bei der Verwendung nie so genau, was im Konstruktor so passiert. Besser ist es die dort ausgeführten Sachen in eigene Funktionen zu packen. Wenn er zum Beispiel etwas aus der DB laden soll kann man die Methode loadFromDB erstellen und sie nachher ausführen.
4. Alle Eigenschaften / Funktionen usw. müssen nach dem gleichen Muster benannt werden. Hier ist zum Beispiel Camel-Casing eine gute Wahl.
5. Benutze keine Tools, die aus deinem Code automatisch eine Doku erzeugen. So muss man im Quellcode wirklich viele Kommentare reinschreiben, die den Code nur zumüllen. An sich sollten Funktionen so sprechend sein, dass sie kein Kommentar benötigt.
6. Benutze Konstanten für feststehende Werte. So kann man zum Beispiel die Mehrwertsteuer o.Ä an einer Stelle festlegen. Ein weiterer Vorteil ist, dass man bei der Ansicht sofort sieht, wofür nun dieser Wert gut ist.
7. Interfaces müssen mit einem I anfangen
8. Interfaces dürfen nur eine Funktionalität (die aber aus mehreren Funktionen bestehen kann) beschreiben.
9. Gleicher Code mehrere Klassen soll in abstrakten Klassen geschrieben sein
10. Jede Variable sollte nur einen Datentyp zugewiesen bekommen
11. Jede Variable soll am Anfang der Funktion o.Ä. initialisiert werden
12. Ein Try-Catch sollte in Klassen nur bestimmte Typen von Exceptions abfangen und nicht allgemein die Exception Klasse. Ausnahme: Die Ausgabe das ein Fehler passiert ist an dem Benutzer.
13. Jede Klasse braucht ihre eigene Datei
14. Klassen sollen so klein wie möglich sein – Es gibt keine Klasse die alles kann
15. Am Anfang jeder Funktion soll die Variable res erstellt werden, die nachher zurückgegeben wird. Ausnahme einzeile Funktionen
16. Benutze wenn vorhanden immer eine passende Funktion der Sprache
17. Benutze so Fremdcode nur, wenn Du selbst verstehst, wie genau es Funktioniert
18. Passe fremden Code nach deinen Richtlinien an, so dass man am besten gar nicht merkt, dass er nicht von dir ist.
19. Erstelle keine Funktionen die später nirgends benötigt werden
20. Lösche Funktionen die nicht mehr gebraucht werden
21. Funktionen sollten so wenig Parameter wie möglich übergeben bekommen – Denn dann machen sie meist mehr als eine Sache. Es sollten max. 3 sein.
22. Funktionen dürfen keine Boolean(true oder false)-Parameter übergeben bekommen – denn dann kann man sie in 2 Funktionen aufteilen
23. Eine Funktion darf niemals null oder nothing zurückgeben. Denn so entstehen später ungewollt Null Reference-Exceptions
24. Werfe Exceptions wenn etwas in deiner Funktion schief läuft
25. Fehlerüberprüfung sollte bestenfalls durch Try-Catch erst am Ende einer Funktion gemacht werden.
26. Erstelle Unit-Testing Funktionen in einer Datei, die fast genauso heißt, wie die zu testende Datei. Beispiel: klasse.php und klasse.test.php.
27. Versuche statt verschachtelte Schleifen bei Datenbankabfragen nur eine Schleife zu nehmen, mit einem guten SQL-Query (z.B. durch Joins und Co).
28. Benutze für Zähler-gesteuerte Schleifen nur die For-Schleife und keine While-Schleife.
29. Benutze kein Break, continue oder Ähnliches in Schleifen usw.
30. Benutze Select-Case statt langen gleichen If-Abfragen.
31. Rücke den Code mit 2 Leerzeichen ein. Keine Tabs, da sie bei verschiedenen Editoren auch verschieden groß sind. Alternativ kann man auch 4 Leerzeichen nehmen.
32. Jede Quellcodezeile sollte maximal 80 Zeichen haben
33. Gruppiere ähnliche Klassen durch Namespaces und passender Ordnerstruktur
34. Übergebe keiner Funktion einen Null oder Nothing.
35. Verwende keine veralteten Funktionen, denn diese werden evtl. Später abgesetzt
36. Stelle deine Compiler / Interpreter so ein, dass auch Warnungen als Fehler interpretiert werden und behebe sie.
37. Erstelle mit deinem Team eigene Entwickler-Richtlinien und achte darauf, dass sie eingehalten werden.
38. Schreibe deinen Quellcode vollständig in Englisch.
39. Trenne die Ausgabe von der Datenverarbeitung.
40. Achte bei Verwendung von Diensten auf fremden Servern darauf, dass sie auch mal ausfallen können. Dann muss eine entsprochene Fehlerbehandlung erstellt werden.
41. Verwende bei der Deklaration von mehreren Variablen die gleichen Positionen. Also das = muss immer übereinander sein.
42. Erstelle Ablaufdiagramme der Programms, um Schwachstellen zu finden.
43. Deklariere Eigenschaften und Funktionen als Private, wenn sie nur in der eigenen Klasse benutzt werden
44. Logge unerwartete Exceptions und behebe sie im Quellcode
45. Denke vorm Speichern immer daran, dass Du den Code evtl. nochmals in ein paar Jahren verstehen musst.

Du arbeitest in einer Agentur oder als Freelancer?
Dann wirf doch mal einen Blick auf unsere Software FeatValue.

Kommentare

Thorsten schrieb am 17.10.2009:

46. Vergebe sinnvolle Function- und Variablennamen *g* zu 45. Deswegen würde ich Kommentar nicht ganz verdammen wollen :)

Stefan Wienströer schrieb am 17.10.2009:

Wenn man die anderen Punkte beachtet braucht man eigentlich keine Kommentare mehr. Aber wenn sie nicht zu lang sind, sind sie in Ordnung.

Christoph schrieb am 17.10.2009:

wenn du auf diese regeln bestehst würdest du aus meinem projekt-team rausfliegen. nicht nur weil du z.b. in regel 18 ggf. zu einem klaren lizenz-verstoss aufrufst, sondern weil einige deiner regeln schlichtweg nicht praxis- und/oder teamtauglich sind. sammle mal 2 jahre erfahrung in einem programmierteam > 10 leute und dann überarbeite das noch mal...

Stefan Wienströer schrieb am 17.10.2009:

Das sind nur Anregungen, natürlich kann man in einem Team nicht alles beachten, aber man sollte sich das ein oder andere schon zu Herzen nehmen. Zu Punkt 18: Da sollte man natürlich die Lizenz beachten. Aber wenn man jetzt nicht ein ganzen Projekt, sondern nur einzelne Klassen und funktionen bekommt, darf man diese oft anpassen. So kann man sicher gehen, das auch alles funktioniert.

nützliche Tweets: 17.10.2009 | preisbiene Blog schrieb am 18.10.2009:

[...] Tipps für sauberen Quellcode (Link) Auch wenn ich nicht mit allem übereinstimme, gibt die Liste doch ein paar Anhaltspunkte [...]

Simon Strasser schrieb am 21.10.2009:

Öhm, ja, sry, aber der Artikel ging etwas in die Hose :) z.B. Punkt 22, da musste ich echt lachen... - Wenn man bei einer komplexeren Anwendung mit dieser Philosophie an die Sache rangeht... mhm, da kann ich mir schon vorstellen, dass das extrem viele Funktionen werden. Eine kleine Rechnung für dich: Nehmen wir an, dass eine Funktion drei Boolean-Werte und weitere Werte übergeben bekommt, in meinem Beispiel heißt die Methode einfach foo(bool,bool,bool,string);: Wenn wir nun für jede Zusammensetzungsmöglichkeit eine eigene Methode schreiben benötigen wir 2³=8 Methoden. Leider habe ich gerade wenig Zeit noch zu anderen Punkten einen ausführlichen Kommentar zu schreiben, aber eines noch: Punkt 36 mag vielleicht während dem Alpha-/Beta-Stadium einer Webanwendung noch halbwegs sinnvoll sein, (wobei ich es persönlich bereits ab dem Beta-Stadium nicht mehr aktivieren würde) in einer Produktivumgebung ist eine solche Einstellung allerdings der GAU.

Stefan Wienströer schrieb am 21.10.2009:

Zu Punkt 22: Man sollte es natürlich nicht übertreiben, aber wenn man zum Beispiel eine Methode mit nur einem Boolean Parameter hat, macht es meiner Meinung nach durchaus sinn. Zu Punkt 36: Da hast Du richt, das sollte wirklich nur in der Entwicklungsphase / auf Testservern so laufen.

Über uns

Wir entwickeln Webanwendungen mit viel Leidenschaft. Unser Wissen geben wir dabei gerne weiter. Mehr über a coding project