7.2.2. Benennung und Packages

Namen in Go sind kurz, konsistent und Teil der API. Clients schreiben immer package.Name – der Package-Name ist damit die erste Silbe jedes exportierten Symbols.

const maxLength = 32
type UserProfile struct{}
func parseHTTPHeader() {}

Exportiert beginnt mit Großbuchstaben (UserProfile), unexportiert mit Kleinbuchstaben (maxLength).

HTTP, URL, ID – immer gleich: ServeHTTP, appID, urlPony. Nicht Http, Url oder Id.

owner := obj.Owner()
obj.SetOwner(user)

Nie this, self oder me. Pro Typ ein kurzer Name auf allen Methoden, z. B. c *Client.

In einer kurzen Funktion reicht c; je weiter die Deklaration vom Gebrauch entfernt ist, desto sprechender der Name.

Kurz, kleingeschrieben, idealerweise ein Wort: http, json, store. Der Verzeichnisname und der package-Name stimmen überein (…/encoding/base64 → package base64).

// package chubby
type File struct{} // Aufruf: chubby.File – nicht chubby.ChubbyFile

Namen wie util, common, misc, api, types, interfaces werden schnell zur Müllhalde und kollidieren. Lieber nach Konzept schneiden:

package stringset

func New(vals ...string) map[string]bool { /* ... */ }

Unexportiert starten; erst exportieren, wenn ein anderes Package den Namen braucht. Stdlib zuerst (net/http, encoding/json, errors, context, io, testing), bevor eine dritte Dependency für 20 Zeilen Helper einzieht – siehe auch 7.2.7. Einfachheit.

Jedes Package braucht einen Kommentar direkt vor der package-Zeile (ohne Leerzeile dazwischen). Details: 7.2.6. Dokumentation und Tests.

Diese Seite gehört zu 7.2. Clean Code.