गो (गोलैंग) कोडिंग मानक

अत्यधिक लम्बी लाइनों से बचें

कोड लाइनों का उपयोग न करें जिससे पाठकों को समर्पित दिशा में स्क्रॉल करना पड़े या दस्तावेज अत्यधिक मोड़ना पड़े।

हम 99 वर्ण तक की लाइन लंबाई की सीमा लगाने की सिफारिश करते हैं। लेखकों को इस सीमा से पहले ही लाइन को तोड़ने की सिफारिश की जाती है, लेकिन यह कठिन नियम नहीं है। कोड को इस सीमा से अधिक होने दिया जा सकता है।

संरूपता

इस दस्तावेज़ में दी गई मानकों में से कुछ अनुसरणीय निर्णयों, परिदृश्यों या संदर्भों पर आधारित होते हैं। हालांकि, सबसे महत्वपूर्ण पहलू यह है कि संरूपता बनाए रखना।

संरूपित कोड को अनुरक्षित रखना, बहुत अधिक तर्कसंगत बनाना, कम शिक्षा लागत मांगना, और नई अनुशासनों या त्रुटियों के उदय होने पर उन्हें स्थानांतरित, अद्यतन और त्रुटियों को ठीक करना आसान हो जाता है।

विपरीतता रूप से, कोडबेस में कई पूरी तरह से भिन्न या विरोधाभासी कोड स्टाइल शामिल करने से रखरखाव लागत, अनिश्चितता, और मानसिक पूर्वाग्रहों में वृद्धि होती है। ये सभी सीधे रूप से धीमी गति, दुखद कोड समीक्षा, और बढ़ते त्रुटियों की संख्या में वृद्धि करती हैं।

कोडबेस पर ये मानकों को लागू करते समय, संकेत (या बड़ा) स्तर पर परिवर्तन करने की सिफारिश की जाती है। उपकेश स्तर पर कई शैलियों को अपनाना उपरोक्त चिंताओं का उल्लंघन करता है।

समान घोषणाओं को समूहित करें

गो भाषा पूर्वोत्तर घोषणाओं का समूहित करने का समर्थन करती है।

सिफारिश नहीं:

import "a"
import "b"

सिफारिश की जाती है:

import (
  "a"
  "b"
)

यह भी स्थायी रूप से लागू होता है: स्थिर, परिवर्तनशील, और प्रकार घोषणाओं के लिए:

सिफारिश नहीं:

const a = 1
const b = 2

var a = 1
var b = 2

type Area float64
type Volume float64

सिफारिश की जाती है:

const (
  a = 1
  b = 2
)

var (
  a = 1
  b = 2
)

type (
  Area float64
  Volume float64
)

केवल संबंधित घोषणाएँ साथ में समूहित करें और असंबंधित घोषणाओं को समूहित करने से बचें।

सिफारिश नहीं:

type Operation int

const (
  Add Operation = iota + 1
  Subtract
  Multiply
  EnvVar = "MY_ENV"
)

सिफारिश की जाती है:

type Operation int

const (
  Add Operation = iota + 1
  Subtract
  Multiply
)

const EnvVar = "MY_ENV"

समूहित करने के लिए कहाँ कोई प्रतिबंध नहीं है इस बात का। उदाहरण के लिए, आप उन्हें एक समूह में प्रयोग कर सकते हैं एक फ़ंक्शन के अंदर:

सिफारिश नहीं:

func f() string {
  red := color.New(0xff0000)
  green := color.New(0x00ff00)
  blue := color.New(0x0000ff)

  ...
}

सिफारिश की जाती है:

func f() string {
  var (
    red   = color.New(0xff0000)
    green = color.New(0x00ff00)
    blue  = color.New(0x0000ff)
  )

  ...
}

अपवाद: यदि चर घोषणाएँ अनुचितता के बावजूद विशेषकर किसी अन्य चरों के साथ समूहित होती हैं, तो उन्हें साथ में समूहित करें। यह विशेषकर फ़ंक्शन-स्थानीय घोषणाओं के भीतर होने पर करें।

सिफारिश नहीं:

func (c *client) request() {
  caller := c.name
  format := "json"
  timeout := 5*time.Second
  var err error
  // ...
}

सिफारिश की जाती है:

func (c *client) request() {
  var (
    caller  = c.name
    format  = "json"
    timeout = 5*time.Second
    err error
  )
  // ...
}

आयात समूहीकरण

आयात को दो श्रेणियों में समूहित किया जाना चाहिए:

• मानक पुस्तकालय
• अन्य पुस्तकालय

गोइंपोर्ट्स द्वारा यह डिफ़ॉल्ट रूप से लागू होता है।

सिफारिश नहीं:

import (
  "fmt"
  "os"
  "go.uber.org/atomic"
  "golang.org/x/sync/errgroup"
)

सिफारिश की जाती है:

import (
  "fmt"
  "os"

  "go.uber.org/atomic"
  "golang.org/x/sync/errgroup"
)

पैकेज नाम

पैकेज का नाम निर्धारण करते समय, इन नियमों का पालन करें:

• सभी छोटे अक्षर, कोई बड़ा अक्षर या अंडरस्कोर नहीं।
• अधिकांश मामलों में, आयात करते समय नामकरण की आवश्यकता नहीं होती।
• संक्षेपित और संक्षिप्त। ध्यान रखें कि नाम हर जगह पूरी रूप से प्रयोग में होता है।
• बहुवचन से बचें। उदाहरण के लिए, net/urls की बजाय net/url का उपयोग करें।
• "common," "util," "shared," या "lib" का उपयोग न करें। ये पर्याप्त सूचनात्मक नहीं हैं।

फ़ंक्शन का नामकरण

हम फ़ंक्शन नामों के लिए MixedCaps के नियम का पालन करते हैं। एक अपवाद उन संबंधित परीक्षण मामलों के लिए किया जाता है, जहां फ़ंक्शन का नाम अंडरस्कोर भी शामिल हो सकता है, जैसे: TestMyFunction_WhatIsBeingTested।

आयात उपनाम

यदि पैकेज का नाम आयात पथ के अंतिम तत्व से मेल नहीं खाता है, तो आयात उपनाम का उपयोग किया जाना चाहिए।

import (
  "net/http"

  client "example.com/client-go"
  trace "example.com/trace/v2"
)

इसके अलावा, आयात उपनामों का उपयोग नहीं किया जाना चाहिए, यदि आयातों के बीच सीधा संघर्ष न हो।

अनुशंसित नहीं:

import (
  "fmt"
  "os"

  nettrace "golang.net/x/trace"
)

अनुशंसित:

import (
  "fmt"
  "os"
  "runtime/trace"

  nettrace "golang.net/x/trace"
)

फ़ंक्शन समूहीकरण और क्रम

• फ़ंक्शन को बड़े आकार में वो क्रम में दिखाया जाना चाहिए जिसमें वो बुलाया जाता है।
• एक ही फ़ाइल के भीतर फ़ंक्शन को रिसीवर द्वारा समूहीकृत किया जाना चाहिए।

इसलिए, निर्यातित फ़ंक्शन फ़ाइल में सबसे पहले आनी चाहिए, struct, const, और var परिभाषाओं के बाद रखी जानी चाहिए।

newXYZ()/NewXYZ() एक उपकरण की परिभाषाओं के बाद लेकिन प्राप्ति के अनुसार पहले आ सकता है।

जैसे ही फ़ंक्शन रिसीवर द्वारा समूहीकृत किए जाते हैं, सामान्य उपयोगी फ़ंक्शन फ़ाइल के अंत में दिखाई देनी चाहिए।

अनुशंसित नहीं:

func (s *something) Cost() {
  return calcCost(s.weights)
}

type something struct{ ... }

func calcCost(n []int) int {...}

func (s *something) Stop() {...}

func newSomething() *something {
    return &something{}
}

अनुशंसित:

type something struct{ ... }

func newSomething() *something {
    return &something{}
}

func (s *something) Cost() {
  return calcCost(s.weights)
}

func (s *something) Stop() {...}

func calcCost(n []int) int {...}

नेस्टिंग कम करें

कोड को मुख्य रूप से गलियारों से कम करना चाहिए, ताकि त्रुटि/विशेष मामलों को जल्द से जल्द संलग्न किया जा सके और या तो वापस लौटा जा सके या फिर लूप जारी रखा जा सके। नेस्टिंग को कम करने से कई स्तरों पर कोड की मात्रा कम होती है।

अनुशंसित नहीं:

for _, v := range data {
  if v.F1 == 1 {
    v = process(v)
    if err := v.Call(); err == nil {
      v.Send()
    } else {
      return err
    }
  } else {
    log.Printf("Invalid v: %v", v)
  }
}

अनुशंसित:

for _, v := range data {
  if v.F1 != 1 {
    log.Printf("Invalid v: %v", v)
    continue
  }

  v = process(v)
  if err := v.Call(); err != nil {
    return err
  }
  v.Send()
}

अनावश्यक नहीं

यदि किसी if की दो शाखाओं में से दोनों में एक ही चर निर्धारित किया जा रहा है, तो उसे एकल if नामक वाक्य से बदला जा सकता है।

अनुशंसित नहीं:

var a int
if b {
  a = 100
} else {
  a = 10
}

अनुशंसित:

a := 10
if b {
  a = 100
}

शीर्ष स्तर पर संचित चर घोषणा

शीर्ष स्तर पर, मानक var का उपयोग करें। त्याग न करें जब तक वह व्यक्ति अभिव्यंति के प्रकार से अलग न हो।

अनुशंसित नहीं:

var _s string = F()

func F() string { return "A" }

अनुशंसित:

var _s = F()
// इसलिए F स्पष्ट रूप से एक स्ट्रिंग प्रकार वापस करता है, हमें _s के लिए प्रकार स्पष्ट रूप से निर्धारित करने की आवश्यकता नहीं है

func F() string { return "A" }

जब एक्सप्रेशन के लिए आवश्यक प्रकार से यदि अनुसरण नहीं करते हैं, तो प्रकार को उपलब्ध कराएं।

type myError struct{}

func (myError) Error() string { return "error" }

func F() myError { return myError{} }

var _e error = F()
// F myError प्रकार का एक उदाहरण लौटाता है, लेकिन हमें error प्रकार की आवश्यकता है

अननुप्रयुक्त शीर्ष-स्तरीय कंस्टेंट्स और वेरिएबल्स के लिए '_' का प्रयोग करें

अननुप्रयुक्त शीर्ष-स्तरीय vars और consts के लिए, उन्हें स्पष्ट रूप से इसकी वैश्विक प्रकृति को संकेत करने के लिए _ अंक के साथ प्रीफिक्स करें।

मूल तर्क: शीर्ष-स्तरीय वेरिएबल्स और कंस्टेंट्स पैकेज स्तर की दृष्टि से होते हैं। सामान्य नामों का उपयोग आसानी से अन्य फ़ाइलों में गलत मान का उपयोग करने की स्थिति में जाने का कारण बन सकता है।

अनुशंसित नहीं:

// foo.go

const (
  defaultPort = 8080
  defaultUser = "user"
)

// bar.go

func Bar() {
  defaultPort := 9090
  ...
  fmt.Println("Default port", defaultPort)

  // यदि Bar() का पहला पंक्ति हटा दी जाए, तो हमें कॉम्पाइल त्रुटि नहीं दिखेगी।
}

अनुशंसित:

// foo.go

const (
  _defaultPort = 8080
  _defaultUser = "user"
)

अपवाद: अननुप्रयुक्त त्रुटि मूल्यों का _ उपयोग किया जा सकता है बिना अंक के प्रीफिक्स के साथ। त्रुटि नामकरण देखें।

स्ट्रक्ट्स में एम्बेडिंग

एम्बेडेड प्रकार (जैसे कि mutex) को स्त्रक्त में फील्ड सूची के शीर्ष पर रखा जाना चाहिए और इसे नियमित पोलो के फील्डों से अलग करने के लिए रिक्त पंक्ति होनी चाहिए।

अनुशंसित नहीं:

type Client struct {
  version int
  http.Client
}

अनुशंसित:

type Client struct {
  http.Client

  version int

एम्बेडिंग को वास्तविक लाभ प्रदान करना चाहिए, जैसे कि सांदर्भिक रूप में कार्य में जोड़ा या सुधारा। यह प्रयोगकर्ता पर किसी भी नकारात्मक प्रभाव के बिना किया जाना चाहिए। (देखें भी: सार्वजनिक स्ट्रक्ट में प्रकारों को एम्बेड न करना)

अपवाद: हटाए गए प्रकारों में भी, म्यूटेक्स को एम्बेड के रूप में उपयोग नहीं करना चाहिए। देखें यद्यपि: शून्य मूल्य म्यूटेक्स मान्य है।

एम्बेडिंग नहीं करना चाहिए:

• सुंदरता या सुविधा के लिए ही मौजूद होना।
• बाहरी प्रकार को निर्माण या उपयोग करना कठिन बनाना।
• उपरोक्त प्रकार का सार्वजनिक सिफर में प्रभाव होना। यदि बाह्य प्रकार का उपयोगकर्ता के द्वारा उपयोगी शून्य मूल्य है, तो बाह्य प्रकार को एम्बेड करने के बाद भी एक उपयोगी शून्य मूल्य होना चाहिए।
• एम्बेड करने के परिणामस्वरूप, एम्बेडेड भीतरी प्रकार से असंबंधित कार्य या फ़ील्ड को व्यक्त करना।
• अननुप्रयुक्त प्रकारों को व्यक्त करना।
• बाहरी प्रकार के clone रूप में प्रभाव डालना।
• बाह्य प्रकार की API या प्रकार समांत्रिकी को बदलना।
• अंदरीकरण प्रकार को गैर-मानक रूप में एम्बेड करना।
• बाह्य प्रकार के कार्य की सामान्य व्यवहार को आप्रयोगिक रूप से बदलना, जिससे प्रयोगकर्ताओं को संतोषजनक नहीं होगा।

संक्षेप में, सजगता और संकल्प से एम्बेड करें। एक अच्छा परीक्षण परीक्षा है, "क्या बाह्य प्रकार से सभी ये प्रकट किए गए पदक/क्षेत्र सीधे बाह्य प्रकार में जोड़े जाएंगे?" यदि उत्तर some याno है, तो अंदरीकृत प्रकार को एम्बेड न करें - बजाय तो क्षेत्रों का प्रयोग करें।

अनुशंसित नहीं:

type A struct {
    // बुरा: A.Lock() और A.Unlock() अब उपलब्ध हैं
    // किसी भी क्रियात्मक लाभ प्रदान नहीं करता और उपयोगकर्ता को A की आंतरिक विवरणों को नियंत्रण करने की अनुमति देता है।
    sync.Mutex
}

अनुशंसित:

type countingWriteCloser struct {
    // अच्छा: एक विशिष्ट उद्देश्य के लिए बाहरी स्तर पर Write() उपलब्ध है, 
    // और कार्य को इनर प्रकार के Write() को सौंपता है।
    io.WriteCloser
    count int
}
func (w *countingWriteCloser) Write(bs []byte) (int, error) {
    w.count += len(bs)
    return w.WriteCloser.Write(bs)
}

स्थानीय चर घोषणाएँ

यदि किसी चर को स्पष्ट रूप से एक मूल्य को सेट किया जाता है, तो चर संक्षिप्त घोषणा रूप (:=) का प्रयोग किया जाना चाहिए।

अनुशंसित नहीं:

var s = "foo"

अनुशंसित:

s := "foo"

हालांकि, कुछ मामलों में, डिफ़ॉल्ट मानों के लिए var शब्द का प्रयोग स्पष्ट हो सकता है।

अनुशंसित नहीं:

func f(list []int) {
  filtered := []int{}
  for _, v := range list {
    if v > 10 {
      filtered = append(filtered, v)
    }
  }
}

अनुशंसित:

func f(list []int) {
  var filtered []int
  for _, v := range list {
    if v > 10 {
      filtered = append(filtered, v)
    }
  }
}

nil एक मान्य स्लाइस है

nil एक मान्य स्लाइस है जिसकी लम्बाई 0 होती है, जिसका मतलब है:

• आपको शून्य लम्बाई की स्लाइस को विशेष रूप से लौटाना नहीं चाहिए। बजाय इसके nil को लौटाएं।

अनुशंसित नहीं:

if x == "" {
  return []int{}
}

अनुशंसित:

if x == "" {
  return nil
}

• एक स्लाइस खाली है या नहीं, यह जांचने के लिए हमेशा len(s) == 0 का उपयोग करें, nil का नहीं।

अनुशंसित नहीं:

func isEmpty(s []string) bool {
  return s == nil
}

अनुशंसित:

func isEmpty(s []string) bool {
  return len(s) == 0
}

• शून्य मूल्य स्लाइस ( var द्वारा घोषित स्लाइस) को make() को बुलाएं बिना सीधे उपयोग किया जा सकता है।

अनुशंसित नहीं:

nums := []int{}
// या, nums := make([]int)

if add1 {
  nums = append(nums, 1)
}

if add2 {
  nums = append(nums, 2)
}

अनुशंसित:

var nums []int

if add1 {
  nums = append(nums, 1)
}

if add2 {
  nums = append(nums, 2)
}

ध्यान रखें, हालांकि निल स्लाइस एक मान्य स्लाइस है, इसे शून्य लंबाई की स्लाइस से बराबर नहीं माना जाता है (एक निल होता है और दूसरा नहीं), और वे विभिन्न स्थितियों में भिन्न रूप से व्यवहार किए जा सकते हैं (जैसे, सीरियलाइज़ेशन में).

चुस्त परिमाण चौड़ा करें

संभावना हो, चुस्त परिमाणों का दायरा छोटा करने की कोशिश करें, जब तक यह घंटी घनाने के नियम के साथ टकराव नहीं करता।

अनुशंसित नहीं:

err := os.WriteFile(name, data, 0644)
if err != nil {
 return err
}

अनुशंसित:

if err := os.WriteFile(name, data, 0644); err != nil {
 return err
}

अगर if स्टेटमेंट के बाहर किसी फ़ंक्शन कॉल के परिणाम का उपयोग किया जाना चाहिए, तो चौड़ाई करने की कोशिश न करें।

अनुशंसित नहीं:

if data, err := os.ReadFile(name); err == nil {
  err = cfg.Decode(data)
  if err != nil {
    return err
  }

  fmt.Println(cfg)
  return nil
} else {
  return err
}

अनुशंसित:

data, err := os.ReadFile(name)
if err != nil {
   return err
}

if err := cfg.Decode(data); err != nil {
  return err
}

fmt.Println(cfg)
return nil

उभारा गया पैमाना टालें

संकेतशून्य पैमानों वाले फ़ंक्शन कॉल में अस्पष्ट पैमाने पढ़ाई को क्षति पहुंचा सकते हैं। जब पैरामीटर नामों का मतलब स्पष्ट न हो, तो पैरामीटर्स के लिए C-स्टाइल टिप्पणियाँ (/* ... */) जोड़ें।

अनुशंसित नहीं:

// func printInfo(name string, isLocal, done bool)

printInfo("foo", true, true)

अनुशंसित:

// func printInfo(name string, isLocal, done bool)

printInfo("foo", true /* isLocal */, true /* done */)

उपरोक्त उदाहरण के लिए, एक बेहतर दृष्टिकोण हो सकता है कि bool प्रकार को कस्टम प्रकारों से बदल दिया जाए। इस तरह, पैरामीटर भविष्य में दो स्थितियों (सही/गलत) के अलावा भी संभावनाओं का समर्थन कर सकता है।

type Region int

const (
  UnknownRegion Region = iota
  Local
)

type Status int

const (
  StatusReady Status= iota + 1
  StatusDone
  // हो सकता है हमें भविष्य में StatusInProgress मिले।
)

func printInfo(name string, region Region, status Status)

भाग्यीय स्ट्रिंग प्रस्तावों का उपयोग करें भाग्यनिक होने के लिए

Go raw string literals का समर्थन करता है, जिसे " ` " द्वारा दिखाया जाता है और यह भाग्यनिक स्ट्रिंग को प्रस्तुत करने के लिए प्रतीत करता है। जहां भाग्यनिकता की आवश्यकता होती है, हमें इस दृष्टि को अधिक पढ़ने वाले मैन्युअल भाग्यीयन स्ट्रिंग को बदलने की नहीं, इस दृष्टि को अंकित करने के लिए इस प्रस्ताव का उपयोग करना चाहिए।

यह कई पंक्तियों तक फैल सकता है और उद्धरण शामिल कर सकता है। इन स्ट्रिंग का उपयोग करने से अधिक पढ़ने वाले मैन्युअल भाग्यीयन स्ट्रिंग से बचाया जा सकता है।

अनुशंसित नहीं:

wantError := "unknown name:\"test\""

अनुशंसित:

wantError := `unknown error:"test"`

संरचना का प्रारंभ करें

क्षेत्र नामों का उपयोग करके संरचनाएँ प्रारंभ करें

संरचना का आरंभ करते समय, क्षेत्र नामों को लगभग हमेशा निर्दिष्ट किया जाना चाहिए। यह वर्तमान में go vet द्वारा प्रवर्तित किया जाता है।

सिफारिश नहीं की जाती:

k := User{"John", "Doe", true}

सिफारिश की जाती है:

k := User{
    FirstName: "John",
    LastName: "Doe",
    Admin: true,
}

अपवाद: जब केवल 3 या उससे कम क्षेत्र होते हैं, तो परीक्षण सारणियों में क्षेत्र नाम छोड़े जा सकते हैं।

tests := []struct{
  op Operation
  want string
}{
  {Add, "add"},
  {Subtract, "subtract"},
}

संरचनाओं में शून्य-मान क्षेत्रों को छोड़ें

नामित क्षेत्रों के साथ संरचना को प्रारंभ करते समय, अर्थपूर्ण संदर्भ प्रदान नहीं करते हैं तो, शून्य मान वाले क्षेत्रों को नजरअंदाज करें। यानी, हमें इन्हें स्वचालित रूप से शून्य मानों पर सेट करने दें।

सिफारिश नहीं की जाती:

user := User{
  FirstName: "John",
  LastName: "Doe",
  MiddleName: "",
  Admin: false,
}

सिफारिश की जाती है:

user := User{
  FirstName: "John",
  LastName: "Doe",
}

इससे सांचनिक मूल्यों को छोड़कर पठनीयता बाधाओं को कम करने में मदद मिलती है। केवल अर्थपूर्ण मानों को निर्दिष्ट करें।

जहाँ संदर्भ में क्षेत्र नामों द्वारा अर्थपूर्ण संदर्भ प्रदान किया जा सकता है, वहाँ शून्य मूल्य का उपयोग करें। उदाहरण के लिए, एक टेबल-ड्राइवन परीक्षण में परीक्षण मामलों में क्षेत्रों का नामकरण करने से फायदा हो सकता है।

tests := []struct{
  give string
  want int
}{
  {give: "0", want: 0},
  // ...
}

शून्य-मान संरच्चनाओं के लिए var का उपयोग करें

यदि संरच्चना के सभी क्षेत्रों को घोषणा में छोड़ दिया गया हो, तो संरच्चना को घोषणा करने के लिए var का उपयोग करें।

सिफारिश नहीं की जाती:

user := User{}

सिफारिश की जाती है:

var user User

इससे शून्य-मान संरच्चनाओं को उन संरच्चनाओं से अलग करता है, जिनमें अशून्य-मान क्षेत्र होते हैं, जैसा कि हम eky tukade ko vyakt karte hain jab hum ek khali slice ghoshit karte hain pe bhi pasand karte hain।

संरचना संदर्भों को प्रारंभ करें

संरचना संदर्भों को प्रारंभ करते समय, संरचना प्रारंभीकरण के लिए new(T) की बजाय &T{} का उपयोग करें।

सिफारिश नहीं की जाती:

sval := T{Name: "foo"}

// असंगत
sptr := new(T)
sptr.Name = "bar"

सिफारिश की जाती है:

sval := T{Name: "foo"}

sptr := &T{Name: "bar"}

मानचित्र को प्रारंभ करें

एक खाली मानचित्र के लिए, उसे make(..) से प्रारंभ करें, और मानचित्र को कार्यक्रमात्मक रूप से भरा जाता है। इससे मानचित्र प्रारंभीकरण घोषणा से भिन्न दिखता है, और यह सुविधाजनक रूप से make के बाद आकार संकेतों को जोड़ने की अनुमति देता है।

सिफारिश नहीं की जाती:

var (
  // m1 is read-write safe;
  // m2 panics when writing
  m1 = map[T1]T2{}
  m2 map[T1]T2
)

सिफारिश की जाती है:

var (
  // m1 is read-write safe;
  // m2 panics when writing
  m1 = make(map[T1]T2)
  m2 map[T1]T2
)

| घोषणा और प्रारंभन बहुत समान दिखते हैं। | घोषणा और प्रारंभन बहुत अलग दिखते हैं। |

जहाँ संभव हो, प्रारंभन के दौरान मानचित्र क्षमता आकार का उल्लेख करें, जानकारी के लिए चित्रित करने के लिए मानचित्र क्षमता निर्दिष्ट करने के लिए अतिरिक्त विवरण देखें।

इसके अतिरिक्त, अगर मानचित्र में निश्चित सूची होती है, तो मानचित्र को प्रारंभ करने के लिए मानचित्र की शाखाएँ उपयोग करें।

सिफारिश नहीं की जाती:

m := make(map[T1]T2, 3)
m[k1] = v1
m[k2] = v2
m[k3] = v3

सिफारिश की जाती है:

m := map[T1]T2{
  k1: v1,
  k2: v2,
  k3: v3,
}

मूल निर्देशिका यह है कि प्रारंभीकरण के दौरान एक निश्चित सेट को जोड़ने के लिए मानचित्र शाखा का उपयोग करें। अन्यथा, make का उपयोग करें (और यदि संभव हो, मानचित्र क्षमता को निर्दिष्ट करें)।

Printf-स्टाइल के फ़ंक्शन के लिए स्ट्रिंग फ़ॉरमैट

अगर आप एक Printf-स्टाइल के फ़ंक्शन के फ़ॉरमैट स्ट्रिंग को एक फ़ंक्शन के बाहर घोषित करते हैं, तो इसे const स्तिर से सेट करें।

इससे go vet को फ़ॉरमैट स्ट्रिंग पर स्थानिक विश्लेषण करने में मदद मिलती है।

सिफारिश नहीं की जाती:

msg := "unexpected values %v, %v\n"
fmt.Printf(msg, 1, 2)

सिफारिश की जाती है:

const msg = "unexpected values %v, %v\n"
fmt.Printf(msg, 1, 2)

Printf-स्टाइल फ़ंक्शनों का नामकरण

Printf-स्टाइल फ़ंक्शनों को घोषित करते समय, सुनिश्चित करें कि go vet स्ट्रिंग का स्वरूप कथन को पहचान और जांच सकता है।

इसका मतलब है कि आपको संभावना होनी चाहिए कि पहले से निर्धारित Printf-स्टाइल फ़ंक्शन नामों का ही उपयोग करें। go vet इन्हें डिफ़ॉल्ट रूप से जांचेगा। अधिक जानकारी के लिए, देखें Printf परिवार।

यदि पहले से निर्धारित नामों का उपयोग नहीं किया जा सकता है, तो चयनित नाम को f के साथ समाप्त करें: Wrapf बजाय Wrap। go vet विशिष्ट Printf-स्टाइल नामों की जांच के लिए अनुरोध कर सकता है, लेकिन नाम को अंत में f से समाप्त करना चाहिए।

go vet -printfuncs=wrapf,statusf