मैं पिछले कुछ दिनों के परिणामों को साझा करना चाहता हूं, जिसमें कुछ बड़े गो परियोजनाओं के इतिहास के गिट विश्लेषण शामिल थे, जो कि उन त्रुटियों को ठीक करने के उद्देश्य से थे जिन्होंने त्रुटियों को ठीक किया और फिर नए कोड में दिखाई देने पर उनका पता लगाने के लिए उन्हें औपचारिक रूप दिया।

लेख के दूसरे भाग में, हम गो-आलोचक में कुछ नए निदानों पर विचार करेंगे, जो आपको ऐसा कोड खोजने की अनुमति देते हैं जिसमें त्रुटि होने की संभावना अधिक होती है।

अतीत में विचारों की खोज करें

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

मान लीजिए आप Go-Files प्रोजेक्ट की जाँच कर रहे हैं। लिंटर (स्थिर विश्लेषक) शुरू करने के बाद, कोई समस्या नहीं है, स्रोत ग्रंथों के ऑडिट ने भी महान परिणाम नहीं लाए। क्या मुझे Go-Files एक तरफ रखना चाहिए? वास्तव में नहीं।

अपने अस्तित्व के दौरान, Go-Files में कई आसानी से पहचाने जाने योग्य दोष थे, लेकिन अब वे पहले से ही तय हो गए हैं। हमें जो करने की जरूरत है वह गिट रिपॉजिटरी के इतिहास का विश्लेषण करना है।

कीड़े कहीं पास में हैं।

हमारे लिए ब्याज का संग्रह

समस्याएं:

• बहुत सारे कमिटमेंट हो सकते हैं
• कभी-कभी एक ही संशोधन में चीजें एक-दूसरे से असंबंधित होती हैं
• कभी-कभी कमेंट पर एक टिप्पणी वास्तविक परिवर्तनों से मेल नहीं खाती है।
• कुछ लोगों ने अच्छे कमिट मैसेज का इस्तेमाल किया है (चलो उंगलियों पर नहीं)

सबसे पहले, हम उन सूचनाओं की मात्रा को कम करना चाहते हैं जिन्हें स्वचालन के बिना संसाधित करना होगा। नमूना आकार (नियंत्रण समूह पर अधिक गो पैकेट डाउनलोड करें) को बढ़ाकर झूठी-नकारात्मक प्रतिक्रियाओं की समस्या को हल किया जा सकता है।

आप इसे अलग-अलग तरीकों से विश्लेषण कर सकते हैं, मैंने बस अपने कमिट मैसेज की सामग्री के आधार पर कमिट के स्कोर को कम करके आंका और कम करके, टेम्प्लेट के सेट के लिए git log --grep किया था। यदि कमिट बहुत बड़ा है, तो आप इसे तुरंत त्याग सकते हैं, क्योंकि यह पता लगाने की बहुत संभावना है कि क्या होता है, यह अनियंत्रित होगा।

मैं यह भी जोड़ना चाहूंगा कि सुधारों के बगल में या त्रुटियों को खोजने में अक्सर बहुत आशावादी नहीं होते हैं और कभी-कभी पैचिंग के बहुत सांस्कृतिक विवरण नहीं होते हैं:

 - "We check length later, but we assumed it was always 1 bytes long. Not always the case. I'm a little depressed that this bug was there" - "Really fixed the bug now" - "WTF, the changes that actually fixed the bug for the accesspattern wasn't actually committed" - "how do i pronounce this damn project" ( traefic) - "damnit travis" - "one f*cking dot" (./.. => ./...  .travis.yml) 

सबसे बेकार "बग फिक्स" सिंटैक्स त्रुटियों या अन्य समस्याओं का संपादन कर रहे हैं जो परियोजना को go build माध्यम से भी संकलन करने से रोकते go build । सभी परियोजनाएं CI या पूर्व-प्रतिबद्ध हुक का उपयोग नहीं करती हैं, इसलिए ऐसे टूटे हुए संशोधन कभी-कभी मास्टर शाखा में समाप्त हो जाते हैं।

ऐतिहासिक त्रुटियां

चलो कुछ सबसे दिलचस्प त्रुटियों के माध्यम से चलते हैं जो गिट लॉग के कवर के तहत पाए गए थे।

वास्तविक परिणाम के बजाय शून्य लौटें

gin-gonic / gin: बग को ठीक करें, विफल होने पर वापस लौटें जब बाध्यकारी बंधन नहीं :

  if err == nil { field.SetBool(boolVal) } - return nil + return err } 

go-pg / pg: AppendParam बग फिक्स :

  return method.AppendValue(b, m.strct.Addr(), 1), true } - return nil, false + return b, false } 

तेज पथ में वापसी का अभाव

गोनम / गोनम: डस्वैप फास्ट पथ में फिक्स्ड बग :

  for i := 0; i < n; i++ { x[i], y[i] = y[i], x[i] } + return } 

Wg.Add के बिना गोरोनाइट चलाना

btcsuite / btcd: RPC सर्वर शटडाउन में कई बग को ठीक करें :

 +s.wg.Add(1) go s.walletListenerDuplicator() 

अमान्य तार्किक स्थिति

gorgonia / gorgonia: कुछ कीड़े भी तय :

 -for i := 0; i > start; i++ { +for i := 0; i < start; i++ { retVal[i] = 0 } 

src-d / go-git: प्लंबिंग / idxfile: मैमोरीइन्डेक्स में खोज को ठीक करें

 -if low < high { +if low > high { break } 

go-xorm / xorm: योग पर बग को ठीक करें :

 -if !strings.Contains(colName, " ") && strings.Contains(colName, "(") { +if !strings.Contains(colName, " ") && !strings.Contains(colName, "(") { 

btcsuite / btcd: सर्वर: फ़िल्टर बग पर डिस्कनेक्ट करने वाले पीयर को ठीक करें :

 -if sp.filter.IsLoaded() { +if !sp.filter.IsLoaded() { 

btcsuite / btcd: अधिकतम संचालन संचालन के साथ उलट परीक्षण बग को ठीक करें :

 -if pop.opcode.value < OP_16 { +if pop.opcode.value > OP_16 { s.numOps++ 

अद्यतन रिसीवर (यह / स्वयं) मूल्य द्वारा पारित

क्लासिक। ऑब्जेक्ट की एक प्रति विधि के अंदर संशोधित की जाती है, जिसके कारण कॉलर को अपेक्षित परिणाम नहीं दिखाई देंगे।

फिक्स्ड एक स्टैक / कतार / deque बग (पॉइंटर रिसीवर) :

 -func (s Stack) Push(x interface{}) { - s = append(s, x) +func (s *Stack) Push(x interface{}) { + *s = append(*s, x) } 

एक लूप के अंदर वस्तुओं की प्रतियां अपडेट करना

समकालिक / ट्रैफिक: स्लाइस में निहित ऐप्स को फ़िल्टर किए गए कार्यों को असाइन करें :

 -for _, app := range filteredApps { - app.Tasks = fun.Filter(func(task *marathon.Task) bool { +for i, app := range filteredApps { + filteredApps[i].Tasks = fun.Filter(func(task *marathon.Task) bool { return p.taskFilter(*task, app) }, app.Tasks).([]*marathon.Task) 

शामिल / ट्रैफिक: पैकेज सुरक्षित के लिए यूनिट परीक्षण जोड़ें :

 -for _, routine := range p.routines { +for i := range p.routines { p.waitGroup.Add(1) - routine.stop = make(chan bool, 1) + p.routines[i].stop = make(chan bool, 1) Go(func() { - routine.goroutine(routine.stop) + p.routines[i].goroutine(p.routines[i].stop) p.waitGroup.Done() }) } 

रैपिंग फ़ंक्शन के परिणाम का उपयोग नहीं किया जाता है।

gorgonia / gorgonia: ग्रैड में एक छोटे गैर-परिणामी बग को फिक्स्ड () :

 if !n.isInput() { - errors.Wrapf(err, ...) - // return + err = errors.Wrapf(err, ...) + return nil, err } 

बनाने के साथ गलत काम

कभी-कभी युवा गोफ़र " make([]T, count) " उसके बाद लूप के अंदर append होते हैं। यहाँ सही विकल्प " make([]T, 0, count) " है।

HouzuoGuo / बंध: एक संग्रह स्कैन बग को ठीक करें :

 -ids := make([]uint64, benchSize) +ids := make([]uint64, 0) 

उपरोक्त सुधार मूल त्रुटि को ठीक करता है, लेकिन एक दोष है जो निम्नलिखित में से एक में तय किया गया था:

 -ids := make([]uint64, 0) +ids := make([]uint64, 0, benchSize) 

लेकिन कुछ ऑपरेशन, जैसे कि copy या ScanSlice को "सही" लंबाई की आवश्यकता हो सकती है।

go-xorm / xorm: बग फिक्स के लिए SumsInt खाली स्लाइस लौटें :

 -var res = make([]int64, 0, len(columnNames)) +var res = make([]int64, len(columnNames), len(columnNames)) if session.IsAutoCommit { err = session.DB().QueryRow(sqlStr, args...).ScanSlice(&res) } else { 

जल्द ही गो-आलोचक इस वर्ग में त्रुटियों को खोजने में मदद करेंगे।

अन्य त्रुटियां

एन्युमरेशन बल्कि बोझिल हो जाता है, मैं बाकी को स्पॉइलर के नीचे ले जाता हूं। यह हिस्सा वैकल्पिक है, इसलिए आप इसे बाद के लिए छोड़ सकते हैं या साहसपूर्वक आगे बढ़ सकते हैं।

 -for _, el := range *s1 { +for el := range *s1 { if _, ok := (*s2)[el]; !ok { return false } 

 func (s *server) Query(ctx context.Context, - req *graph.Request) (resp *graph.Response, err error) { + req *graph.Request) (*graph.Response, error) { + resp := new(graph.Response) 

 -block, err := btcutil.NewBlockFromBytes(blockBytes) +block, err = btcutil.NewBlockFromBytes(blockBytes) if err != nil { return err } 

 -err = session.Rollback() +err1 := session.Rollback() +if err1 == nil { + return lastId, err +} +err = err1 

 -debugPrint("Listening and serving HTTP on %s", addr) +debugPrint("Listening and serving HTTP on %s\n", addr) 

  styleCache map[int]*Style `-` + lock *sync.RWMutex } 

संदिग्ध कोड के खिलाफ धर्मयुद्ध

badCond

badCond चेक संभावित गलत तार्किक अभिव्यक्ति पाता है।

संदिग्ध तार्किक अभिव्यक्तियों के उदाहरण:

• परिणाम हमेशा true या false
• अभिव्यक्ति एक ऐसे रूप में लिखी गई है जो त्रुटिपूर्ण से लगभग अप्रभेद्य है

यह चेक " x == nil && x == y " जैसे ऑपरेशन पर भी काम करता है। एक सरल उपाय " x == nil && y == nil " को फिर से लिखना है। कोड की पठनीयता को नुकसान नहीं होता है, लेकिन लिंटर को इस कोड में कुछ भी संदिग्ध नहीं दिखाई देगा।

यहाँ बग फिक्स का एक उदाहरण है जो badCond द्वारा पाया जा सकता है:

 -if err1 := f(); err != nil && err == nil { +if err1 := f(); err1 != nil && err == nil { err = err1 } 

ट्राफी:

• moby / buildkit: स्नैपशॉट: असंभव स्थिति को ठीक करें
• tdewolff / parse: use.go से बराबरी की अजीब स्थिति है
• हौज़ुओगुओ / बंध: httpapi: srv_test.go में संदिग्ध स्थिति

weakCond

weakCond के समान है, लेकिन अलर्ट का आत्मविश्वास स्तर थोड़ा कम है।

एक कमजोर स्थिति एक ऐसी स्थिति है जो इनपुट को पूरी तरह से पर्याप्त रूप से कवर नहीं करती है।

कमजोर (अपर्याप्त) स्थिति का एक अच्छा उदाहरण nil लिए स्लाइस की जांच करना और फिर पहले तत्व का उपयोग करना है। यहां " s != nil " स्थितियां पर्याप्त नहीं हैं। सही स्थिति " len(s) != 0 " या इसके समतुल्य है:

 func addRequiredHeadersToRedirectedRequests( req *http.Request, via []*http.Request) error { - if via != nil && via[0] != nil { + if len(via) != 0 && via[0] != nil { 

ट्राफी:

• etcd-io / etcd: वेंडर्स / एपी / v2v3: लिनल चेक के बिना नील जाँच के बाद अनुक्रमण
• moby / मोबाई: रजिस्ट्री: बिना चेक के नील जाँच के बाद अनुक्रमण
• inkyblackness / hacked: ss1 / content / text: बिना len check के nil check के बाद index करना

dupArg

कुछ कार्यों के लिए, एक ही मान (या चर) को कई तर्कों के रूप में पारित करने से बहुत अर्थ नहीं निकलता है। अक्सर, यह एक कॉपी / पेस्ट त्रुटि का संकेत देता है।

ऐसे फ़ंक्शन का एक उदाहरण copy । एक्सप्रेशन copy(xs, xs) कोई मतलब नहीं है।

 -if !bytes.Equal(i2.Value, i2.Value) { +if !bytes.Equal(i1.Value, i2.Value) { return fmt.Errorf("tries differ at key %x", i1.Key) } 

ट्राफी:

• Ethereum / go-ethereum: light: बाइट्स में डुप्लिकेट किए गए तर्क को ठीक करें। ईक्वल कॉल
• खुलता है / उत्पत्ति: प्रतिबिंबित को ठीक करें। डीपक्वेल (एक्स, एक्स) बग

dupCase

आप शायद जानते हैं कि गो में आप switch अंदर डुप्लिकेट case वैल्यूज़ का उपयोग नहीं कर सकते।

नीचे दिया गया उदाहरण संकलित नहीं है :

 switch x := 0; x { case 1: fmt.Println("first") case 1: fmt.Println("second") } 

संकलन त्रुटि: स्विच में डुप्लिकेट केस 1।

लेकिन क्या होगा अगर हम एक उदाहरण और अधिक दिलचस्प लेते हैं :

 one := 1 switch x := 1; x { case one: fmt.Println("first") case one: fmt.Println("second") } 

डुप्लिकेट मान चर के माध्यम से अनुमति दी जाती है। इसके अलावा, switch true त्रुटियों के लिए और भी अधिक जगह देता है:

 switch x := 0; true { case x == 1: fmt.Println("first") case x == 1: fmt.Println("second") } 

और यहाँ एक वास्तविक त्रुटि को ठीक करने का एक उदाहरण है:

 switch { case m < n: // Upper triangular matrix. //   . case m == n: // Diagonal matrix. //   . -case m < n: // Lower triangular matrix. +case m > n: // Lower triangular matrix. //   . } 

ट्राफी:

• मेलियम / sasl: डुप्लिकेट किए गए स्विच केस को हटा दें
• गोनम / गोनम: डुप्लिकेट किए गए स्विच केस को ठीक करें
• पैक्ट-फाउंडेशन / पैक्ट-गो: डुप्लिकेटेड स्विच केस को हटा दें
• minio / minio: cmd / object-api-error.go में संदिग्ध डुप्लिकेट स्विच केस क्लॉज
• henrylee2cn / pholcus: सामान्य / बाइट्स: डुप्लिकेट किए गए स्विच केस को हटा दें
• go-ble / ble: linux / att: डुप्लिकेट किए गए स्विच केस की त्रुटि को ठीक करें
• डॉकटर / वितरण: रजिस्ट्री / भंडारण: डुप्लिकेट किए गए स्विच केस को ठीक करें

dupBranchBody

सशर्त विवरण जैसे if/else और switch करने के लिए निकाय हैं। जब शर्त पूरी हो जाती है, तो संचालन की संबंधित इकाई पर नियंत्रण स्थानांतरित कर दिया जाता है। हालांकि अन्य डायग्नोस्टिक्स यह सत्यापित करते हैं कि इन ब्लॉकों की स्थितियां भिन्न हैं, फिर भी dupBranchBody जांचता है कि निष्पादन योग्य ब्लॉक स्वयं पूरी तरह से समान नहीं हैं।

सशर्त बयानों के अंदर डुप्लिकेट निकायों की उपस्थिति, जब तक कि यह एक type switch है, कम से कम संदिग्ध है।

 -if s, err := r.ReceivePack(context.Background(), req); err != nil { - return s, err -} else { - return s, err -} +return r.ReceivePack(context.Background(), req) 

नीचे दिए गए कोड की शुद्धता की डिग्री के बारे में निर्णय पाठक पर छोड़ दिए जाते हैं:

 if field.IsMessage() || p.IsGroup(field) { //   . } else if field.IsString() { if nullable && !proto3 { p.generateNullableField(fieldname, verbose) } else { pP(`if this.`, fieldname, ` != that1.`, fieldname, `{`) } } else { if nullable && !proto3 { p.generateNullableField(fieldname, verbose) } else { pP(`if this.`, fieldname, ` != that1.`, fieldname, `{`) } } } 

" if field.IsString() " और संबद्ध " else " के अंदर निकाय समान हैं।

ट्राफी:

• src-d / go-git: संदिग्ध डुप्लिकेटेड शाखा निकाय

caseOrder

सभी प्रकार के अंदर type switch पहले क्रमिक रूप से क्रमिक रूप type switch क्रमबद्ध type switch । यदि टैग का मान टाइप *T , और इम्प्लीमेंट इंटरफ़ेस I , तो आपको " case I " के साथ लेबल से पहले " case *T " के साथ एक लेबल लगाना होगा, अन्यथा केवल " case I " को निष्पादित किया जाएगा, क्योंकि *T I के साथ संगत है (लेकिन इसके विपरीत नहीं)।

 case string: res = append(res, NewTargetExpr(v).toExpr().(*expr)) -case Expr: - res = append(res, v.toExpr().(*expr)) case *expr: res = append(res, v) +case Expr: + res = append(res, v.toExpr().(*expr)) 

ट्राफी:

• cmd / गुरु: वर्णन में गलत केस क्रम को ठीक करें
• संदेश / पाइपलाइन: फिक्स टाइप स्विच केस ऑर्डर
• coyove / goflyway: प्रॉक्सी: केस ऑर्डर को एक प्रकार के स्विच में ठीक करें
• go-graphite / carbonapi: pkg / parser: फिक्स टाइप स्विच केस ऑर्डर

offBy1

प्रति यूनिट त्रुटि इतनी लोकप्रिय है कि इसका अपना विकिपीडिया पृष्ठ भी है ।

 if len(optArgs) > 1 { return nil, ErrTooManyOptArgs } -node = optArgs[1] +node = optArgs[0] 

 -last := xs[len(xs)] +last := xs[len(xs) - 1] 

इस तरह की त्रुटियों को खोजने के लिए go-critic पास सीमित विकल्प हैं, लेकिन अभी तक एक भी फिक्स को सार्वजनिक रिपॉजिटरी में नहीं भेजा गया है। यहाँ कुछ फिक्सेस दिए गए हैं जो कहानी देखते समय दिए गए हैं:

• btcsuite / btcd: getaddednodeinfo में बग्स का परीक्षण करें और उन्हें ठीक करें
• btcsuite / btcd: परीक्षण कवरेज में सुधार और परीक्षणों द्वारा पाए गए कुछ कीड़े को ठीक करें

अंत में थोड़ा डर

go vet में " x != a || x != b " जैसे भावों की अच्छी जाँच है। ऐसा लगता है कि लोगों को gometalinter बारे में नहीं पता हो सकता है, लेकिन go vet gometalinter लगभग सभी को लॉन्च करता है, है ना?

गोगरेप उपयोगिता का उपयोग करते हुए, मैंने समान अभिव्यक्तियों की एक छोटी सूची को एक साथ रखा , जो अभी भी कुछ परियोजनाओं की मास्टर शाखाओं में हैं।

 cloud.google.com/go/trace/trace_test.go:943:7: expectTraceOption != ((o2&1) != 0) || expectTraceOption != ((o3&1) != 0) github.com/Shopify/sarama/mocks/sync_producer_test.go:36:5: offset != 1 || offset != msg.Offset github.com/Shopify/sarama/mocks/sync_producer_test.go:44:5: offset != 2 || offset != msg.Offset github.com/docker/libnetwork/api/api_test.go:376:5: id1 != i2e(i2).ID || id1 != i2e(i3).ID github.com/docker/libnetwork/api/api_test.go:408:5: "sh" != epList[0].Network || "sh" != epList[1].Network github.com/docker/libnetwork/api/api_test.go:1196:5: ep0.ID() != ep1.ID() || ep0.ID() != ep2.ID() github.com/docker/libnetwork/api/api_test.go:1467:5: ep0.ID() != ep1.ID() || ep0.ID() != ep2.ID() github.com/docker/libnetwork/ipam/allocator_test.go:1261:5: len(indices) != len(allocated) || len(indices) != num github.com/esimov/caire/grayscale_test.go:27:7: r != g || r != b github.com/gogo/protobuf/test/bug_test.go:99:5: protoSize != mSize || protoSize != lenData github.com/gogo/protobuf/test/combos/both/bug_test.go:99:5: protoSize != mSize || protoSize != lenData github.com/gogo/protobuf/test/combos/marshaler/bug_test.go:99:5: protoSize != mSize || protoSize != lenData github.com/gogo/protobuf/test/combos/unmarshaler/bug_test.go:99:5: protoSize != mSize || protoSize != lenData github.com/gonum/floats/floats.go:65:5: len(dst) != len(s) || len(dst) != len(y) github.com/gonum/lapack/testlapack/dhseqr.go:139:7: wr[i] != h.Data[i*h.Stride+i] || wr[i] != h.Data[(i+1)*h.Stride+i+1] github.com/gonum/stat/stat.go:1053:5: len(x) != len(labels) || len(x) != len(weights) github.com/hashicorp/go-sockaddr/ipv4addr_test.go:659:27: sockaddr.IPPort(p) != test.z16_portInt || sockaddr.IPPort(p) != test.z16_portInt github.com/hashicorp/go-sockaddr/ipv6addr_test.go:430:27: sockaddr.IPPort(p) != test.z16_portInt || sockaddr.IPPort(p) != test.z16_portInt github.com/nats-io/gnatsd/server/monitor_test.go:1863:6: v.ID != c.ID || v.ID != r.ID github.com/nbutton23/zxcvbn-go/adjacency/adjcmartix.go:85:7: char != "" || char != " " github.com/openshift/origin/pkg/oc/cli/admin/migrate/migrator_test.go:85:7: expectedInfos != writes || expectedInfos != saves github.com/openshift/origin/test/integration/project_request_test.go:120:62: added != deleted || added != 1 github.com/openshift/origin/test/integration/project_request_test.go:126:64: added != deleted || added != 4 github.com/openshift/origin/test/integration/project_request_test.go:132:62: added != deleted || added != 1 gonum.org/v1/gonum/floats/floats.go:60:5: len(dst) != len(s) || len(dst) != len(y) gonum.org/v1/gonum/lapack/testlapack/dhseqr.go:139:7: wr[i] != h.Data[i*h.Stride+i] || wr[i] != h.Data[(i+1)*h.Stride+i+1] gonum.org/v1/gonum/stat/stat.go:1146:5: len(x) != len(labels) || len(x) != len(weights) 

दूसरों की गलतियों से सीखना

नहीं, यहां तक ​​कि अंतिम भाग में मशीन लर्निंग के बारे में कुछ भी नहीं होगा।

लेकिन यहाँ जो लिखा जाएगा वह गोलंग्स्की-लिंट के बारे में है, जिसने नवीनतम रिलीज़ में से एक में गो-आलोचक को एकीकृत किया है। golangci-lint का एक एनालॉग है, जिसे आप इसके लाभों के बारे में पढ़ सकते हैं, उदाहरण के लिए, लेख में "गो में स्थैतिक विश्लेषण: कोड की जाँच करते समय हम समय कैसे बचाते हैं । "

go-critic को हाल ही में लिंटपैक का उपयोग करके फिर से लिखा गया है। विवरण गो लिंटपैक में पाया जा सकता है : एक संयोजक लिंटर मैनेजर ।

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

सभी के लिए अच्छा है।