Ruby Style Guide

Dokument in der Entstehungsphase...

Winfried Mueller, www.reintechnisch.de, Start: 09.06.05, Stand: -

Es gibt schlechten Stil, Programme zu schreiben. Wer seine Zeilen nicht korrekt einrückt, darf ruhigen Gewissens als Chaot bezeichnet werden. Genauso, wer gleiche Dinge immer wieder auf unterschiedliche Weise umsetzt.

Guter Stil dagegen ist nicht klar definiert und auch Geschmackssache. Autos sind in der Regel alle irgendwie wohlgeformt, auch wenn nicht jedes Auto jedem gefällt. Welcher Stil bevorzugt wird, hängt auch von der bisherigen Erfahrung ab. Was der eine als schön und passend empfindet, stört den anderen.

Was aber auf jeden Fall für jeden Programmierer irgendwann dran sein sollte: Sich Gedanken darüber zu machen, welchem Stil ich folgen will. Und es kann gut sein, wenn sich ein Team auf einen gemeinsamen Stil einigt. Code kann so für alle verständlicher werden.

Dieses Style-Guide ist mein Versuch, einen vernünftigen Stil für Ruby-Programme zu finden. Dabei habe ich mich von meiner Erfahrung leiten und von anderen inspirieren lassen. Ich denke, dieses Style-Guide, kann auch andere inspirieren, um seinen eigenen Stil zu finden.

Grundsätzliches

  • Einrückung 2 Leerzeichen - Bei nahezu allen Projekten in unterschiedlichsten Programmiersprachen hat sich dies als bester Kompromiss herausgestellt. Tabs mag ich nicht, weil es immer korrekte Tab-Einstellungen bei unterschiedlichsten Editoren voraussetzt. Das Argument, dass damit die Dateien kürzer werden, ist bei interpretierenden Sprache sicherlich zu beachten, aber ich denke, eher marginal. Mehr als 2 Zeichen Einrückung empfinde ich als ungünstig, weil dann die maximale Zeilenlänge zu schnell erreicht wird.
  • Zeilenlänge 76 Zeichen - Oft sind noch 80 Zeichen-Displays im Einsatz. Wenn rechts und links wegen eines Rahmens noch 1-2 Zeichen wegfallen, sind 76 Zeichen das Maximum. Erfahrungsgemäß ist das ein guter Kompromiss, der auch bei der Programmierung nicht stört. Auch ausdrucken oder per Mail versenden lässt sich so ein Dokument gut. In Ausnahmenfällen darf eine Zeile auch mal länger sein.
  • Kommentare über Codezeile - Kommentare, die über einer Codezeile angeordnet sind, schaffen eine bessere Lesbarkeit, als wenn man sie rechts neben den Code schreibt. Nur in Ausnahmen sollte man von dieser Regel abweichen.
  • Code-Absätze - Code sollte durch eine Leerzeile in mehrere Absätze bzw. Abschnitte unterteilt sein. Zusammengehörige Teile werden direkt untereinander geschrieben, sobald jedoch eine neue logische Einheit kommt, wird eine Leerzeile gesetzt. Logisch zusammengehöriges lässt sich so besser erkennen.

Klassen

  • Klassennamen CamelCase - Klassennamen beginnen mit einem Großbuchstaben. Setzt sich der Name aus mehreren Wörtern zusammen, wird der erste Buchstabe des nächsten Wortes groß geschrieben und direkt angehängt. Dies ist die Art, die von den meisten in Ruby forciert wird.
  • attr* ganz oben - Direkt nach der Klassendefinition sollten noch vor allen Methoden die attr_* Statements folgen. So erkennt man sofort am Anfang der Klasse, welche öffentlichen Attribute eine Klasse hat. Das entspricht auch der Reihenfolge im UML-Modell. Anstatt als Liste, bietet es sich oft an, jedes Attribut auf eine Extra Zeile mit attr_* zu setzen, um es darüber besser dokumentieren zu können.

Methoden

  • Methodennamen mit Unterstrich - Methodennamen werden durchweg klein geschrieben. Mehrere Wörter werden mit einem Unterstrich verbunden, z.B. "call_block". Dies ist eine Konvention, wie sie in Ruby üblich ist.
  • Kurz und gut - Methoden bestehen in der Regel aus wenigen Zeilen. Eine Methode, die mehr als 50-100 Zeilen hat, ist schon verdächtig, dass da mehrere Funktionalitäten miteinander vermischt worden. Meist findet sich einiges, was man in weitere Methoden auslagern kann.
  • Eine Aufgabe - Eine Methode sollte eine Aufgabe lösen und nicht ein Mischmasch aus mehreren Problemlösungen. Der Methodenname gibt dabei an, was die Methode tut.