नामकरण परंपराएं और शैली

गो में मजबूत और गैर-परक्राम्य नामकरण और शैली परंपराएं हैं: आधिकारिक फ़ॉर्मेटर gofmt (और इसका सुपरसेट goimports) इंडेंटेशन, स्पेसिंग और आयात ऑर्डर तय करता है। शैली पर चर्चा करना विषय से परे माना जाता है: आप gofmt -w चलाते हैं और आगे बढ़ते हैं। यह अधिक दिलचस्प समस्याओं के लिए ऊर्जा मुक्त करता है।

दृश्यता: अपरकेस या लोअरकेस

कोई public/private कीवर्ड नहीं हैं। नाम का पहला अक्षर दृश्यता निर्धारित करता है:

• अपरकेस → पैकेज के बाहर निर्यात किया गया (User, Login, MaxRetries)।
• लोअरकेस → पैकेज के लिए निजी (user, parseLine, defaultTimeout)।

यह इस पर लागू होता है: प्रकार, कार्य, विधियाँ, चर, स्थिरांक, संरचना क्षेत्र।

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

एक "निजी" संरचना फ़ील्ड **encoding/json (मॉड्यूल 8 देखें) द्वारा क्रमबद्ध नहीं है, और यह pkg_test में परीक्षणों से पहुंच योग्य नहीं है।

कैमलकेस, कभी स्नेक_केस नहीं

बहु-शब्द नामों में कोई अंडरस्कोर नहीं:

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

एक्रोनिम्स सभी अपरकेस में जाते हैं (या सभी लोअरकेस, यदि निजी दायरे में हों):

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

type APIResponse struct {
    UserID  int
    HTMLURL string
}

छोटे दायरे के लिए संक्षिप्त नाम

गो शैली संकीर्ण दायरे में समान स्पष्टता के साथ संक्षिप्तता का समर्थन करती है:

// 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) { ... }

स्थापित परंपराएँ:

• लूप इंडेक्स के लिए i, j, k।
• मानों के लिए v, कुंजियों के लिए k।
• *Request/io.Reader के लिए r, Writer/ResponseWriter के लिए w।
• त्रुटियों के लिए err।
• ctx के लिए context.Context।
• विधि रिसीवर: पूरे प्रकार में 1-2 सुसंगत अक्षर (s *Server, u *User)। कभी भी this या self नहीं।

दायरा जितना व्यापक होगा, नाम उतना ही अधिक वर्णनात्मक होना चाहिए: एक स्थानीय count ठीक है, लेकिन एक निर्यातित Count चर आपको बताएगा कि यह क्या मायने रखता है।

इंटरफ़ेस पर कोई "I" उपसर्ग नहीं, कोई "Impl" प्रत्यय नहीं

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

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

छोटे इंटरफ़ेस अक्सर -er प्रत्यय लेते हैं: Reader, Writer, Stringer, Closer। यह इस तथ्य को प्रतिध्वनित करता है कि वे एक व्यवहार (आदर्श रूप से एक एकल विधि) का वर्णन करते हैं।

पैकेज के नाम

एक पैकेज में एक ही नाम, संक्षिप्त, सभी लोअरकेस, कोई अंडरस्कोर नहीं है:

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

पैकेज का नाम इसके प्रतीकों का उपयोग उपसर्ग है: bytes.Buffer, http.Client। इसलिए user.User अनावश्यक है: प्रकार (user.Account) या पैकेज का नाम बदलना बेहतर है।

gofmt बहस के लिए तैयार नहीं है

gofmt लागू करता है:

• टैब के साथ इंडेंटेशन (रिक्त स्थान नहीं)।
• हस्ताक्षर के समान पंक्ति में { को बांधें।
• एक रिक्त रेखा द्वारा अलग किए गए समूहों में आयात; goimports अनुपलब्ध आयात भी जोड़ता है।
• ऑपरेटरों के आसपास की जगहें।

प्रतिबद्ध होने से पहले हमेशा दौड़ें:

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

लिंटर (staticcheck, golangci-lint) अतिरिक्त नियम जोड़ते हैं (अप्रयुक्त चर, छायांकन, बेकार तुलना, ...)।

अभ्यास

type ??? struct {}