RuboCop: Stilregeln und Fehlerprüfung für Ruby

Ruby hat eine freiwillige, aber sehr wirkungsvolle Regelsprache: RuboCop prüft Stil, Komplexität, Sicherheitsaspekte und mögliche Fehler. Für Teams ist sie der praktikabelste Weg, Diskussionen über Formatierung durch eine maschinelle Entscheidung zu ersetzen. Dieser Artikel zeigt die wichtigsten Regeln und den Umgang mit Ausnahmen.

Wichtige RuboCop-Cops

RuboCop arbeitet mit Cops, also einzelnen Regeln in Kategorien. Die folgenden sind die, die im Alltag am häufigsten relevant sind.

Stil und Lesbarkeit

  • Style/StringLiterals: doppelte oder einfache Anführungszeichen einheitlich. Voreinstellung ist doppelt; viele Projekte stellen auf einfache um.
  • Style/FrozenStringLiteralComment: verlangt den Kommentar # frozen_string_literal: true am Dateianfang. Er verhindert, dass Zeichenkettenliterale bei jeder Verwendung neu erzeugt werden – messbar weniger Speicherbedarf.
  • Style/Documentation: erwartet einen Kommentar über jeder Klasse und jedem Modul. In Bibliotheken sinnvoll, in Anwendungscode oft abgeschaltet.
  • Style/GuardClause: verlangt eine Wächterklausel statt tief verschachtelter Bedingungen: früh return, statt den Hauptweg einzurücken.
  • Style/RedundantReturn: Ruby gibt den letzten Ausdruck automatisch zurück – ein explizites return ist überflüssig.
  • Style/IfUnlessModifier: einzeilige if-Blöcke als Modifier schreiben, solange die Zeile lesbar bleibt.
  • Style/NumericLiterals: große Zahlen mit Unterstrichen gliedern: 1_000_000.

Metriken und Komplexität

  • Metrics/MethodLength: Methoden maximal eine bestimmte Anzahl Zeilen. Standard 10 – eine gute Richtschnur, auch wenn einzelne Ausnahmen vertretbar sind.
  • Metrics/ClassLength und Metrics/ModuleLength: Grenzen für die Gesamtgröße. Werden sie gerissen, ist meist eine Aufteilung in mehrere Verantwortlichkeiten die richtige Antwort.
  • Metrics/AbcSize: kombiniert Zuweisungen, Verzweigungen und Aufrufe. Ein hoher Wert zeigt eine Methode, die zu viele Dinge gleichzeitig tut.
  • Metrics/CyclomaticComplexity: zählt Entscheidungspfade. Ab etwa 10 wird eine Methode schwer testbar, weil die Anzahl der Fälle explodiert.
  • Metrics/BlockNesting: maximale Verschachtelungstiefe. Drei Ebenen sind meist genug.

Häufige Fehlerquellen

  • Lint/UselessAssignment: Variablen, die gesetzt und nie gelesen werden – häufig ein Rest nach einer Umstellung.
  • Lint/UnusedMethodArgument: Argumente, die niemand nutzt. Bei Überschreibungen in Vererbungshierarchien ist ein Unterstrich-Präfix die übliche Kennzeichnung.
  • Lint/ShadowingOuterLocalVariable: Ein Blockparameter verdeckt eine äußere Variable. Die Folge sind sehr verwirrende Fehler.
  • Lint/DuplicateMethods: dieselbe Methode zweimal definiert – die erste Definition ist wirkungslos.
  • Lint/Void: Ausdrücke ohne Wirkung.

Sicherheit

  • Security/Eval: warnt vor eval und ähnlichen Konstrukten. Mit Nutzereingaben ist das ein direkter Weg zur Codeausführung.
  • Security/MarshalLoad: Marshal.load auf fremden Daten kann beliebigen Code ausführen.
  • Security/Open: open mit Nutzereingabe ermöglicht Kommandoausführung. Stattdessen URI.open mit geprüfter Eingabe verwenden.
  • Security/YAMLLoad: empfiehlt YAML.safe_load statt YAML.load.

Bedienung

rubocop                              # alles prüfen
rubocop app lib                      # nur bestimmte Pfade
rubocop -a                           # sichere Korrekturen automatisch
rubocop -A                           # auch unsichere Korrekturen
rubocop --only Metrics/MethodLength  # eine einzelne Regel
rubocop --except Style/Documentation
rubocop --format json > bericht.json # maschinenlesbar
rubocop --auto-gen-config            # Ausnahmen in .rubocop_todo.yml sammeln

# Als Editor-Integration
# .rubocop.yml mit require: rubocop-rails, rubocop-rspec

Konfiguration und Umgang mit Ausnahmen

# .rubocop.yml
AllCops:
  TargetRubyVersion: 3.4
  NewCops: enable

Style/StringLiterals:
  EnforcedStyle: single_quotes

Metrics/MethodLength:
  Max: 15

Metrics/BlockLength:
  Exclude:
    - 'spec/**/*'
    - 'db/migrate/**/*'

Style/Documentation:
  Enabled: false

Lint/UnusedMethodArgument:
  AllowUnusedKeywordArguments: true

Der wichtigste Rat im Umgang mit RuboCop: rubocop --auto-gen-config als Einstieg. Es erzeugt eine Datei .rubocop_todo.yml mit den aktuellen Verstößen als Ausnahmen. Damit ist die Prüfung sofort grün, und man kann die Ausnahmen schrittweise abbauen, statt erst tausende Verstöße beheben zu müssen. Ohne diesen Weg wird die Regelprüfung in bestehenden Projekten meist nach wenigen Tagen abgeschaltet.

Ebenfalls hilfreich: Regeln pro Verzeichnis lockern. In Tests sind lange Methoden und mehr Verschachtelung normal; eine Ausnahme für spec/**/* ist ehrlicher als eine weltweit gelockerte Grenze.

Verwandte Grundlagen: Ruby-Befehle, Linter, Refactoring, Code-Review.