7.2. Clean Code

Clean Code in Go heißt: klarer Kontrollfluss, kleine Schnittstellen, explizite Fehler und Code, den Menschen und Werkzeuge gleichermaßen lesen können. Das Ziel ist dasselbe wie in 4. Clean Code – aber die Mittel sind andere. Go hat keine Vererbungshierarchie, kein festes Klassenmodell und keine „Clean Code“-Buchregeln als Sprachstandard. Maßgeblich sind Effective Go, die Code Review Comments und die Go Proverbs.

Eine 1:1-Übersetzung aus Java oder C++ ergibt selten idiomatisches Go. Statt Klassenbaum und Framework-Schichten: kleine Packages, Komposition und Interfaces, die der Verbraucher definiert.

type Server struct {
	store Store
	log   *slog.Logger
}

Leitlinien:

• Clear is better than clever – offensichtlicher Ablauf vor cleveren Tricks; Reflection nur, wenn nötig.
• Errors are values – Fehler zurückgeben und prüfen, nicht verstecken.
• Composition, not inheritance – Verhalten zusammensetzen, nicht ableiten.
• Make the zero value useful – var x T sollte möglichst sofort brauchbar sein.
• Gofmt für alle – Layout entscheiden die Werkzeuge, nicht der Geschmack.

Wenn Quellen sich widersprechen, gilt diese Reihenfolge:

1. Official Go (Effective Go, Code Review Comments, Release Notes, pkg.go.dev)
2. Go Proverbs
3. Google Go Style Guide
4. Uber Go Style Guide – als Teamstil markieren, wenn strenger als Official

Robert C. Martins „Clean Code“ ist kein Go-Primärstandard. SOLID und Code Smells aus Kapitel 4 bleiben nützlich als Denkhilfe; die konkreten Idiome kommen aus den Go-Dokumenten.

Die Beispiele und Stdlib-Hinweise setzen Go 1.27 oder neuer voraus. Features, die neuer sind als die go-Zeile im Modul, gehören nicht in den Code – auch wenn sie „moderner“ wirken.