हम गो के लिए एक नए लिंटर (स्थिर विश्लेषक) की घोषणा कर रहे हैं, जो स्थैतिक विश्लेषण की दुनिया में आपके विचारों को प्रदर्शित करने के लिए एक सैंडबॉक्स भी है।

गो-आलोचक निम्नलिखित टिप्पणियों के आसपास बनाया गया है:

• परीक्षण के "अच्छा पर्याप्त" कार्यान्वयन के लिए बेहतर है कि यह बिल्कुल न हो
• यदि चेक विवादास्पद है, तो इसका मतलब यह नहीं है कि यह उपयोगी नहीं हो सकता है। हम "राय" के रूप में चिह्नित करते हैं और डालते हैं
• स्क्रैच से लिंटर लिखना आम तौर पर मौजूदा ढांचे में एक नया चेक जोड़ने की तुलना में अधिक कठिन होता है यदि फ्रेमवर्क को समझना आसान है।

इस पोस्ट में हम गो-आलोचक के उपयोग और वास्तुकला को देखेंगे, इसमें लागू किए गए कुछ चेक , और इसमें हमारे विश्लेषक फ़ंक्शन को जोड़ने के लिए मुख्य चरणों का भी वर्णन करेंगे।

जल्दी शुरू करो

$ cd $GOPATH $ go get -u github.com/go-critic/go-critic/... $ ./bin/gocritic check-package strings $GOROOT/src/strings/replace.go:450:22: unslice: could simplify s[:] to s $GOROOT/src/strings/replace.go:148:2: elseif: should rewrite if-else to switch statement $GOROOT/src/strings/replace.go:156:3: elseif: should rewrite if-else to switch statement $GOROOT/src/strings/replace.go:219:3: elseif: should rewrite if-else to switch statement $GOROOT/src/strings/replace.go:370:1: paramTypeCombine: func(pattern string, value string) *singleStringReplacer could be replaced with func(pattern, value string) *singleStringReplacer $GOROOT/src/strings/replace.go:259:2: rangeExprCopy: copy of r.mapping (256 bytes) can be avoided with &r.mapping $GOROOT/src/strings/replace.go:264:2: rangeExprCopy: copy of r.mapping (256 bytes) can be avoided with &r.mapping $GOROOT/src/strings/strings.go:791:1: paramTypeCombine: func(s string, cutset string) string could be replaced with func(s, cutset string) string $GOROOT/src/strings/strings.go:800:1: paramTypeCombine: func(s string, cutset string) string could be replaced with func(s, cutset string) string $GOROOT/src/strings/strings.go:809:1: paramTypeCombine: func(s string, cutset string) string could be replaced with func(s, cutset string) string $GOROOT/src/strings/strings.go:44:1: unnamedResult: consider to give name to results $GOROOT/src/strings/strings.go:61:1: unnamedResult: consider to give name to results $GOROOT/src/strings/export_test.go:28:3: rangeExprCopy: copy of r.mapping (256 bytes) can be avoided with &r.mapping $GOROOT/src/strings/export_test.go:42:1: unnamedResult: consider to give name to results 

(चेतावनियों का प्रारूपण संपादित किया गया है; मूल जीस्ट में उपलब्ध हैं।)

Gocritic उपयोगिता अलग-अलग पैकेजों को उनके आयात पथ ( check-package ) द्वारा जांच सकती है, और सभी निर्देशिकाओं ( check-project ) की पुनरावृत्ति भी कर सकती है। उदाहरण के लिए, आप पूरे $GOROOT या $GOPATH को एक ही कमांड से देख सकते हैं:

 $ gocritic check-project $GOROOT/src $ gocritic check-project $GOPATH/src 

स्पष्ट रूप से सूचीबद्ध करने के लिए चेक के लिए "श्वेत सूची" के लिए समर्थन है जो चेक ( -enable ध्वज) किया जाना चाहिए। डिफ़ॉल्ट रूप से, सभी चेक जो कि Experimental या VeryOpinionated आइकन से चिह्नित नहीं हैं, VeryOpinionated जाते VeryOpinionated ।

गॉलैन्स्की-लिंट और गोमेटालिटर्न में एकीकरण की योजना बनाई गई है ।

यह सब कैसे शुरू हुआ

गो परियोजना की अगली कोड समीक्षा का संचालन करना, या कुछ 3-आरडी पार्टी लाइब्रेरी का ऑडिट करना, आप एक ही समस्या को बार-बार नोटिस कर सकते हैं।

आपके अफसोस के लिए, एक लिंटर को ढूंढना संभव नहीं था जो समस्याओं के इस वर्ग का निदान करेगा।

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

लेकिन क्या होगा अगर चेक पूरी तरह से अस्पष्ट है और किसी के द्वारा भी व्यक्तिपरक या अपर्याप्त रूप से सटीक माना जा सकता है?

शायद यह समझ में आता है कि इस जाँच को स्वयं लिखने का प्रयास करें?

go-critic प्रायोगिक परीक्षणों के लिए एक घर बनने के लिए मौजूद है जो कि मौजूदा स्थैतिक विश्लेषक के लिए उन्हें संलग्न करने की तुलना में खुद को लागू करना आसान है। go-critic उपकरण स्वयं ही एक नई जाँच जोड़ने के लिए आवश्यक संदर्भ और क्रियाओं की मात्रा को कम कर देता है - हम कह सकते हैं कि आपको केवल एक फ़ाइल जोड़ने की आवश्यकता है (परीक्षणों की गिनती नहीं)।

कैसे काम करता है आलोचक

एक आलोचक नियमों का एक समूह है जो चेक गुणों और माइक्रो- चेकर्स का वर्णन करता है जो एक नियम के अनुपालन के लिए कोड निरीक्षण को लागू करते हैं।

एक एप्लिकेशन जो एक लिंटर को एम्बेड करता है (उदाहरण के लिए, cmd / gocritic या golangci-lint ) समर्थित नियमों की एक सूची प्राप्त करता है, उन्हें एक विशिष्ट तरीके से फ़िल्टर करता है, प्रत्येक चयनित नियम के लिए एक चेक फ़ंक्शन बनाता है, और उनमें से प्रत्येक को अध्ययन के तहत पैकेज पर लॉन्च करता है।

एक नया चेकर जोड़ने का काम तीन मुख्य चरणों में उबलता है:

1. परीक्षण जोड़ना।
2. सत्यापन का कार्यान्वयन स्वयं।
3. लिंटर के लिए प्रलेखन जोड़ना।

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

टेस्ट जोड़ना

एक नए चेक के लिए परीक्षण डेटा जोड़ने के लिए, आपको लिंट / टेस्टडेटा में एक नई निर्देशिका बनाने की आवश्यकता है।

प्रत्येक ऐसी निर्देशिका में एक positive_tests.go फ़ाइल होनी चाहिए, जो कोड उदाहरणों का वर्णन करती है, जिस पर चेक काम करना चाहिए। झूठी सकारात्मकता की अनुपस्थिति का परीक्षण करने के लिए, परीक्षणों को एक "सही" कोड के साथ पूरक किया जाता है, जिसमें नए चेक को कोई समस्या नहीं मिलनी चाहिए ( negative_tests.go )।

उदाहरण:

 // lint/testdata/positive_tests.go /// consider `in' name instead of `IN' /// `X' should not be capitalized /// `Y' should not be capitalized /// `Z' should not be capitalized func badFunc1(IN, X int) (Y, Z int) { /// `V' should not be capitalized V := 1 return V, 0 } 

 // lint/testdata/negative_tests.go func goodFunc1(in, x int) (x, y int) { v := 1 return v, 0 } 

आप एक नया लिंटर जोड़ने के बाद परीक्षण चला सकते हैं।

सत्यापन कार्यान्वयन

चेकर के नाम के साथ एक फ़ाइल बनाएँ: lint/captLocal_checker.go ।
सम्मेलन द्वारा, सभी माइक्रो-लिंटर फ़ाइलों में _checker प्रत्यय है।

 package lint //  “Checker”    . type captLocalChecker struct { checkerBase upcaseNames map[string]bool } 

checkerBase एक प्रकार है जिसे प्रत्येक चेकर में एम्बेड किया जाना चाहिए।
यह डिफ़ॉल्ट कार्यान्वयन प्रदान करता है, जो आपको प्रत्येक लिंटर में कम कोड लिखने की अनुमति देता है।
अन्य बातों के अलावा, checkerBase में lint.context का एक पॉइंटर शामिल है, जिसमें टाइप की गई जानकारी और फ़ाइल की जाँच की जा रही अन्य मेटाडेटा शामिल हैं।

upcaseNames क्षेत्र में ज्ञात नामों की एक तालिका होगी, जिसे हम upcaseNames साथ बदलने की पेशकश करेंगे। upcaseNames strings.ToLower(name) संस्करण। उन नामों के लिए जो मानचित्र में सम्‍मिलित नहीं हैं, यह सुझाव दिया जाएगा कि कैपिटल लेटर का उपयोग न करें, लेकिन कोई सही प्रतिस्थापन प्रदान नहीं किया जाएगा।

आंतरिक अवस्था को प्रत्येक उदाहरण के लिए एक बार प्रारंभ किया जाता है।
Init() विधि को केवल उन लिंटर्स के लिए परिभाषित किया जाना आवश्यक है, जिन्हें प्रारंभिक आरंभीकरण करने की आवश्यकता है।

 func (c *captLocalChecker) Init() { c.upcaseNames = map[string]bool{ "IN": true, "OUT": true, "INOUT": true, } } 

अब आपको चेकिंग फ़ंक्शन को स्वयं परिभाषित करने की आवश्यकता है।
captLocal के मामले में, हमें सभी स्थानीय ast.Ident जांच करने की आवश्यकता है जो नए चर पेश करते हैं।

नामों की सभी स्थानीय परिभाषाओं की जांच करने के लिए, आपको अपने परीक्षक में निम्नलिखित हस्ताक्षर के साथ एक विधि लागू करनी चाहिए:

 VisitLocalDef(name astwalk.Name, initializer ast.Expr) 

उपलब्ध विज़िटर इंटरफेस की सूची फ़ाइल लिंट / आंतरिक / विज़िटर में देखी जा सकती है।
captLocal लागू LocalDefVisitor ।

 //  ast.Expr,         //  .      . func (c *captLocalChecker) VisitLocalDef(name astwalk.Name, _ ast.Expr) { switch { case c.upcaseNames[name.ID.String()]: c.warnUpcase(name.ID) case ast.IsExported(name.ID.String()): c.warnCapitalized(name.ID) } } func (c *captLocalChecker) warnUpcase(id *ast.Ident) { c.ctx.Warn(id, "consider `%s' name instead of `%s'", strings.ToLower(id.Name), id) } func (c *captLocalChecker) warnCapitalized(id ast.Node) { c.ctx.Warn(id, "`%s' should not be capitalized", id) } 

अधिवेशन के द्वारा, चेतावनियों को उत्पन्न करने वाले तरीकों को आमतौर पर अलग-अलग तरीकों में रखा जाता है। दुर्लभ अपवाद हैं, लेकिन इस नियम का पालन करना अच्छा अभ्यास माना जाता है।

प्रलेखन जोड़ना

एक अन्य आवश्यक कार्यान्वयन विधि है InitDocumentation :

 func (c *captLocalChecker) InitDocumentation(d *Documentation) { d.Summary = "Detects capitalized names for local variables" d.Before = `func f(IN int, OUT *int) (ERR error) {}` d.After = `func f(in int, out *int) (err error) {}` } 

आमतौर पर, केवल 3 फ़ील्ड भरें:

• Summary - एक वाक्य में सत्यापन कार्रवाई का विवरण।
• Before - सुधार से पहले कोड।
• After - सुधार के बाद कोड (चेतावनी का कारण नहीं होना चाहिए)।

एक नया लिंटर रजिस्टर करें और परीक्षण चलाएं

अंतिम स्पर्श एक नए लिंटर को पंजीकृत कर रहा है:

 //   captLocal_checker.go init . func init() { addChecker(&captLocalChecker{}, attrExperimental, attrSyntaxOnly) } 

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

attrSyntaxOnly , attrSyntaxOnly लिए एक वैकल्पिक मार्कर है जो उनके कार्यान्वयन में टाइप जानकारी का उपयोग नहीं करता है, जो आपको टाइप चेक किए बिना उन्हें चलाने की अनुमति देता है। golangci-lint ऐसे लिंटर को "तेज़" झंडे से चिह्नित करता है (क्योंकि वे बहुत तेज़ी से चलते हैं)।

attrExperimental एक विशेषता है जिसे सभी नए कार्यान्वयनों को सौंपा गया है। कार्यान्वित चेक के स्थिरीकरण के बाद ही इस विशेषता को हटाना संभव है।

अब जब नया लिंटर एड-चेकर के माध्यम से पंजीकृत है, तो आप परीक्षण चला सकते हैं:

 #  GOPATH: $ go test -v github.com/go-critic/go-critic/lint #  GOPATH/src/github.com/go-critic/go-critic: $ go test -v ./lint #  ,      make: $ make test 

आशावादी विलय (लगभग)

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

हमारे पास दो लिंटर मार्कर भी हैं जिनका उपयोग पूर्ण सहमति के अभाव में लाल झंडे से बचने के लिए किया जा सकता है:

1. Experimental : एक कार्यान्वयन में झूठी सकारात्मक की एक बड़ी मात्रा हो सकती है, अप्रभावी हो सकती है (समस्या का स्रोत पहचाना जाता है), या कुछ स्थितियों में "गिरावट"। यदि आप इसे attrExperimental विशेषता के साथ चिह्नित करते हैं, तो आप इस तरह के कार्यान्वयन को attrExperimental हैं। कभी-कभी, प्रायोगिक की मदद से, उन जांचों को इंगित किया जाता है जो पहली प्रतिबद्ध से एक अच्छा नाम खोजने में विफल रहीं।
2. VeryOpinionated : यदि चेक में दोनों रक्षकों और दुश्मन हो सकते हैं, तो यह विशेषता attrVeryOpinionated साथ चिह्नित करने के लायक है। इस तरह, हम कोड शैली के बारे में विचारों को अस्वीकार करने से बच सकते हैं जो कुछ गॉफ़रों के स्वाद से मेल नहीं खा सकते हैं।

Experimental से एक संभावित अस्थायी और निर्धारण योग्य कार्यान्वयन संपत्ति है। VeryOpinionated एक अधिक मौलिक नियम संपत्ति है जो स्वतंत्र रूप से लागू हो रही है।

कार्यान्वयन प्रस्तुत करने से पहले जीथब पर एक [checker-request] टिकट बनाने की सिफारिश की जाती है, लेकिन यदि आपने पहले ही एक पुल अनुरोध प्रस्तुत किया है, तो आप इसके लिए संबंधित मुद्दा खोल सकते हैं।

विकास प्रक्रिया के बारे में अधिक जानकारी के लिए, CONTRIBUTING.md देखें।
मूल नियम मुख्य नियम अनुभाग में सूचीबद्ध हैं।

बिदाई शब्द

आप न केवल नए लिंटर जोड़कर परियोजना में भाग ले सकते हैं।
कई अन्य तरीके हैं:

• इसे अपनी परियोजनाओं या बड़े / प्रसिद्ध ओपन-सोर्स प्रोजेक्ट्स पर आज़माएँ और झूठी सकारात्मक, गलत नकारात्मक और अन्य कमियों की रिपोर्ट करें। हम आभारी होंगे यदि आप ट्रॉफी पृष्ठ पर पाई गई समस्या के बारे में एक नोट जोड़ते हैं।
• नए निरीक्षण के लिए सुझाव दें। यह हमारे ट्रैकर पर एक मुद्दा बनाने के लिए पर्याप्त है।
• मौजूदा लिंटर के लिए परीक्षण जोड़ें।

go-critic आपके गो कोड की आलोचना करता है, इसके विकास में शामिल सभी प्रोग्रामरों की आवाज़ के साथ। हर कोई आलोचना कर सकता है, इसलिए - शामिल हों!