Adlandırma kuralları ve stili

Go'nun güçlü ve tartışılamaz adlandırma ve stil kuralları vardır: resmi biçimlendirici gofmt (ve onun üst kümesi goimports) girintiye, aralıklara ve içe aktarma sırasına karar verir. Stili tartışmak konu dışı kabul edilir: gofmt -w komutunu çalıştırırsınız ve devam edersiniz. Bu, daha ilginç problemler için enerji tasarrufu sağlar.

Görünürlük: büyük harf veya küçük harf

public/private anahtar kelime yok. Adın ilk harfi görünürlüğü belirler:

• Büyük harf → paketin dışına aktarılır (User, Login, MaxRetries).
• Küçük harf → pakete özel (user, parseLine, defaultTimeout).

Bu şunlar için geçerlidir: türler, işlevler, yöntemler, değişkenler, sabitler, yapı alanları.

type User struct {
    Name  string  // exported
    email string  // private to the package
}

"Özel" bir yapı alanı AGYTOK_INLINE_11__ tarafından serileştirilmez (bkz. Modül 8) ve pkg_test içindeki testlerden erişilemez.

CamelCase, asla Snake_case

Çok kelimeli adlarda alt çizgi yoktur:

• ✅ HTTPClient, userName, parseRequest
• ❌ Http_Client, user_name, parse_request

Kısaltmaların tamamı büyük harfle yazılır (veya özel kapsamdaysa tamamı küçük harfle yazılır):

• ✅ URL, ID, HTML, JSON, parseURL, userID
• ❌ Url, Id, Html, Json, parseUrl, userId

type APIResponse struct {
    UserID  int
    HTMLURL string
}

Kısa kapsamlar için kısa adlar

Go stili, dar kapsamlarda eşit netlikte kısalığı tercih eder:

// idiomatic
for i, v := range items { ... }
for k, v := range m { ... }

if err := f(); err != nil { ... }

func (s *Server) Serve(w http.ResponseWriter, r *http.Request) { ... }

Yerleşik sözleşmeler:

• Döngü endeksleri için i, j, k.
• Değerler için v, anahtarlar için k.
• *Request/io.Reader için r, Writer/ResponseWriter için w.
• hatalar için err.
• context.Context için ctx.
• Yöntem alıcıları: Tüm tür boyunca 1-2 tutarlı harf (s *Server, u *User). Asla this veya self.

Kapsam ne kadar geniş olursa, adın da o kadar açıklayıcı olması gerekir: yerel bir count iyidir, ancak dışa aktarılan bir Count değişkeni size neyin önemli olduğunu söylemelidir.

Arayüzlerde "I" öneki yok, "Impl" son eki yok

// idiomatic
type Reader interface { ... }
type fileReader struct { ... } // concrete implementation

// not idiomatic
type IReader interface { ... }
type ReaderImpl struct { ... }

Küçük arayüzler genellikle -er son ekini alır: Reader, Writer, Stringer, Closer. Bir davranışı (ideal olarak tek bir yöntemi) tanımladıkları gerçeğini yansıtır.

Paket adları

Bir paketin tek bir adı vardır, kısadır, tümü küçük harftir, alt çizgi yoktur:

• ✅ bytes, http, os, userauth
• ❌ userAuth, user_auth, UserAuth

Paket adı, sembollerinin kullanım önekidir: bytes.Buffer, http.Client. Dolayısıyla user.User gereksizdir: türü (user.Account) veya paketi yeniden adlandırmak daha iyidir.

gofmt tartışmaya açık değil

gofmt şunu zorunlu kılar:

• sekmeler ile girinti (boşluk değil).
• {'yi imzayla aynı satıra parantez içine alın.
• Boş bir satırla ayrılmış gruplar halinde içe aktarmalar; goimports ayrıca eksik içe aktarmaları da ekler.
• Operatörlerin etrafındaki boşluklar.

Taahhüt etmeden önce daima çalıştırın:

go fmt ./...
goimports -w .
go vet ./...

Linterler (staticcheck, golangci-lint) ekstra kurallar ekler (kullanılmayan değişkenler, gölgeleme, gereksiz karşılaştırmalar, ...).

Egzersizler

type ??? struct {}