लिंटरपैक लिंटर (स्थिर विश्लेषक) के निर्माण के लिए एक उपयोगिता है, जो कि उपलब्ध एपीआई का उपयोग करके लिखे गए हैं। इसके आधार पर, गो-आलोचक स्थिर विश्लेषक, जो कुछ से परिचित है, अब फिर से लिखा जा रहा है।

आज हम अधिक विस्तार से lintpack करेंगे कि उपयोगकर्ता के दृष्टिकोण से lintpack क्या lintpack ।

शुरुआत में गो-आलोचक थे ...

गो-आलोचक एक पायलट प्रोजेक्ट के रूप में शुरू हुआ जो कि गो के लिए लगभग किसी भी स्थिर विश्लेषण विचारों के प्रोटोटाइप के लिए एक सैंडबॉक्स था।

एक सुखद आश्चर्य यह था कि कुछ लोगों ने कोड में विभिन्न समस्याओं के डिटेक्टरों के कार्यान्वयन को भेजा। तब तक सब कुछ नियंत्रण में था जब तक एक तकनीकी ऋण जमा नहीं होने लगा, जिसे समाप्त करने के लिए व्यावहारिक रूप से कोई नहीं था। लोग आए, सत्यापन जोड़ा, और फिर गायब हो गए। फिर त्रुटियों को सुधारने और कार्यान्वयन को संशोधित करने के लिए कौन है?

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

एक और कठिनाई थी एक्स्टेंसिबिलिटी। हर कोई अपने कोड को किसी और के भंडार में भेजने में सहज नहीं है। कुछ अपने चेक को गतिशील रूप से जोड़ना चाहते थे ताकि उन्हें go-critic स्रोत कोड को संशोधित करने की आवश्यकता न हो।

संक्षेप में, यहां वे समस्याएं हैं जो go-critic विकास के रास्ते में थीं:

जटिलता का भार। बहुत समर्थन, एक मालिकहीन कोड की उपस्थिति।
कम औसत गुणवत्ता। experimental अर्थ है "लगभग उपयोग करने के लिए तैयार" और "बेहतर नहीं बिल्कुल भी नहीं चलाना।"
कभी-कभी यह तय करना मुश्किल हो जाता है कि क्या सत्यापन को go-critic में शामिल किया जाए, और उन्हें अस्वीकार करने से मूल डिज़ाइन दर्शन का विरोधाभास होता है।
अलग go-critic अलग लोगों ने go-critic अलग तरह से देखा। अधिकांश इसे एक सीआई लिंटर के रूप में लेना चाहते थे, जो कि gometalinter साथ आता है।

किसी तरह परियोजना की विसंगतियों और असंगत व्याख्याओं की संख्या को सीमित करने के लिए, एक घोषणापत्र लिखा गया था।

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

लेकिन क्या होगा अगर हमें एक रिपॉजिटरी में सभी चेक स्टोर करने की आवश्यकता नहीं है?

मिलना - लिंटपैक

प्रोजेक्ट लोगो का प्रारंभिक संस्करण

go-critic में दो मुख्य घटक होते हैं:

चेकों का कार्यान्वयन स्वयं।
एक प्रोग्राम जो गो-वैलिड पैकेज को डाउनलोड करता है और उन पर सत्यापन चलाता है।

हमारा लक्ष्य: विभिन्न रिपॉजिटरी में लिंटर के लिए चेक स्टोर करने में सक्षम होना और आवश्यक होने पर उन्हें एक साथ इकट्ठा करना।

लिंटपैक बस यही करता है। यह उन कार्यों को परिभाषित करता है जो आपको अपनी जांच का वर्णन इस तरह से करने की अनुमति देते हैं कि आप उन्हें उत्पन्न लिंटर के माध्यम से चला सकते हैं।

एक ढांचे के रूप में lintpack का उपयोग करने वाले पैकेज को lintpack रूप में संदर्भित किया lintpack संगत या lintpack - lintpack पैकेज।

यदि go-critic को lintpack के आधार पर लागू go-critic गया था, तो सभी जांचों को कई रिपॉजिटरी में विभाजित किया जा सकता है। अलगाव के विकल्पों में से एक निम्नलिखित हो सकता है:

मुख्य सेट जहां सभी स्थिर और समर्थित चेक मिलते हैं।
कंट्री रिपॉजिटरी जहां कोड निहित है या तो बहुत प्रयोगात्मक है या एक अनुचर की कमी है।
एक विशिष्ट परियोजना के लिए अनुकूलन योग्य जाँच।

गोलंग्स्की-लिंट में गो-आलोचक के एकीकरण के संबंध में पहला बिंदु विशेष महत्व का है।

यदि आप go-critic स्तर पर बने रहते हैं, तो उपयोगकर्ताओं के लिए लगभग कुछ भी नहीं बदला है। lintpack लगभग समान लिंटर बनाता है, जबकि golangci-lint सभी अलग golangci-lint अलग कार्यान्वयन विवरणों को golangci-lint करता है।

लेकिन कुछ बदल गया है। यदि नए lintpack को lintpack के आधार पर बनाया जाता है, तो आपके पास लिंटर पैदा करने के लिए तैयार डायग्नोस्टिक्स का समृद्ध चयन होगा। एक पल के लिए कल्पना करें कि यह ऐसा है, और दुनिया में 10 से अधिक अलग-अलग चेक हैं।

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

आरंभ करने के लिए, आपको lintpack स्वयं स्थापित lintpack :

 # lintpack    `$(go env GOPATH)/bin`. go get -v github.com/go-lintpack/lintpack/...

lintpack से टेस्ट पैकेज का उपयोग करके एक लिंटर बनाएं:

 lintpack build -o mylinter github.com/go-lintpack/lintpack/checkers

सेट में panic(nil) शामिल है, जो कोड में panic(nil) पाता है और कुछ अलग करने के साथ प्रतिस्थापन के लिए panicNil , क्योंकि अन्यथा recover() यह बताने में सक्षम नहीं होगा कि panic को nil तर्क के साथ बुलाया गया था, या कोई आतंक नहीं था।

घबराहट (शून्य) के साथ उदाहरण

नीचे दिए गए कोड recover() से प्राप्त मूल्य का वर्णन करने का प्रयास करते हैं recover() :

 r := recover() fmt.Printf("%T, %v\n", r, r)

परिणाम panic(nil) और एक कार्यक्रम के लिए समान होगा जो panic(nil) नहीं करता है।

वर्णित व्यवहार का एक रन उदाहरण ।

आप लाइनर को अलग-अलग फ़ाइलों पर, प्रकार के तर्कों के साथ शुरू कर सकते हैं ./... या पैकेज (उनके आयात पथ द्वारा)।

 ./mylinter check bytes $GOROOT/src/bytes/buffer_test.go:276:3: panicNil: panic(nil) calls are discouraged

 #   ,  go-lintpack    $GOPATH. mylinter=$(pwd)/mylinter cd $(go env GOPATH)/src/github.com/go-lintpack/lintpack/checkers/testdata $mylinter check ./panicNil/ ./panicNil/positive_tests.go:5:3: panicNil: panic(nil) calls are discouraged ./panicNil/positive_tests.go:9:3: panicNil: panic(interface{}(nil)) calls are discouraged

डिफ़ॉल्ट रूप से, यह चेक panic(interface{}(nil)) भी प्रतिक्रिया करता है। इस व्यवहार को ओवरराइड करने के लिए, skipNilEfaceLit को true सेट करें। आप इसे कमांड लाइन के माध्यम से कर सकते हैं:

 $mylinter check -@panicNil.skipNilEfaceLit=true ./panicNil/ ./panicNil/positive_tests.go:5:3: panicNil: panic(nil) calls are discouraged

सीएमडी / लिंटपैक और उत्पन्न लिंटर के लिए उपयोग

lintpack और उत्पन्न लिंटर दोनों एक उपकमांड का चयन करने के लिए पहले तर्क का उपयोग करते हैं। उपलब्ध लॉन्च की सूची और उनके लॉन्च के उदाहरणों को तर्क के बिना उपयोगिता को कॉल करके प्राप्त किया जा सकता है।

 lintpack not enough arguments, expected sub-command name Supported sub-commands: build - build linter from made of lintpack-compatible packages $ lintpack build -help $ lintpack build -o gocritic github.com/go-critic/checkers $ lintpack build -linter.version=v1.0.0 . version - print lintpack version $ lintpack version

मान लीजिए कि हमने बनाये गए लिंटर का नाम gocritic :

 ./gocritic not enough arguments, expected sub-command name Supported sub-commands: check - run linter over specified targets $ linter check -help $ linter check -disableTags=none strings bytes $ linter check -enableTags=diagnostic ./... version - print linter version $ linter version doc - get installed checkers documentation $ linter doc -help $ linter doc $ linter doc checkerName

-help फ़्लैग कुछ उपखंडों के लिए उपलब्ध है, जो अतिरिक्त जानकारी प्रदान करता है (मैंने कुछ पंक्तियों को बहुत चौड़ा काट दिया):

 ./gocritic check -help #     .

इंस्टॉल किए गए चेक का दस्तावेजीकरण

इस सवाल का जवाब "बहुत स्किपनेटाइलसिट पैरामीटर के बारे में कैसे पता करें?" - फैंसी मैनुअल (RTFM) पढ़ें!

इंस्टॉल किए गए चेक के बारे में सभी दस्तावेज mylinter अंदर हैं। यह दस्तावेज doc उपकमांड के माध्यम से उपलब्ध है:

 #     : $mylinter doc panicNil [diagnostic] #      : $mylinter doc panicNil panicNil checker documentation URL: github.com/go-lintpack/lintpack Tags: [diagnostic] Detects panic(nil) calls. Such panic calls are hard to handle during recover. Non-compliant code: panic(nil) Compliant code: panic("something meaningful") Checker parameters: -@panicNil.skipNilEfaceLit bool whether to ignore interface{}(nil) arguments (default false)

go list -f में टेम्पलेट्स के लिए समर्थन की तरह go list -f , आप एक टेम्प्लेट स्ट्रिंग पास कर सकते हैं जो दस्तावेज़ीकरण के आउटपुट स्वरूप के लिए ज़िम्मेदार है, जो मार्कडाउन दस्तावेज़ लिखते समय उपयोगी हो सकता है।

स्थापना के लिए चेक कहां देखें?

उपयोगी lintpack सूट की खोज को आसान बनाने के लिए, lintpack की एक केंद्रीयकृत सूची lintpack संगत पैकेज: https://go-lintpack.imtqy.com/ ।

यहाँ कुछ सूची दी गई है:

यह सूची समय-समय पर अद्यतन की जाती है और इसके अलावा अनुरोधों के लिए खुला है। लिंटर बनाने के लिए इनमें से किसी भी पैकेज का इस्तेमाल किया जा सकता है।

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

 #   ,      #   Go . go get -v github.com/go-critic/go-critic/checkers go get -v github.com/go-critic/checkers-contrib # build   . lintpack build \ github.com/go-critic/go-critic/checkers \ github.com/go-critic/checkers-contrib

lintpack build में संकलन चरण में सभी जांच शामिल हैं, परिणामस्वरूप लिंटर को ऐसे वातावरण में रखा जा सकता है जहां स्थापित निदान के कार्यान्वयन के लिए कोई स्रोत कोड नहीं हैं, सब कुछ सामान्य रूप से स्थैतिक लिंकिंग के साथ है।

डायनेमिक पैकेज अटैचमेंट

स्थैतिक असेंबली के अलावा, अतिरिक्त चेक प्रदान करने वाले प्लगइन्स को लोड करना संभव है।

ख़ासियत यह है कि चेकर कार्यान्वयन को यह नहीं पता है कि इसका उपयोग स्थैतिक संकलन के लिए किया जाएगा या प्लग-इन के रूप में लोड किया जाएगा। कोड में कोई बदलाव की आवश्यकता नहीं है।

माना कि हम लिंटर में panicNil को जोड़ना चाहते हैं, लेकिन हम उन सभी स्रोतों से इसका पुनर्निर्माण नहीं कर पा रहे हैं, जिनका इस्तेमाल पहले संकलन के दौरान किया गया था।

linterPlugin.go बनाएँ:

 package main //         , //    import'. import ( _ "github.com/go-lintpack/lintpack/checkers" )

एक गतिशील पुस्तकालय बनाएँ:

 go build -buildmode=plugin -o linterPlugin.so linterPlugin.go

-pluginPath पैरामीटर के साथ -pluginPath चलाएँ:

 ./linter check -pluginPath=linterPlugin.so bytes

चेतावनी: गतिशील मॉड्यूल के लिए समर्थन एक प्लगइन पैकेज के माध्यम से कार्यान्वित किया जाता है जो विंडोज पर काम नहीं करता है।

-verbose ध्वज आपको यह पता लगाने में मदद कर सकता है कि कौन सा चेक चालू है या बंद है, और सबसे महत्वपूर्ण बात यह है कि यह दिखाएगा कि किस चेक ने चेक को निष्क्रिय कर दिया है।

उदाहरण -verbose के साथ

ध्यान दें कि शामिल जाँचों की सूची में panicNil प्रदर्शित panicNil । अगर हम -pluginPath तर्क को हटा दें, तो यह सत्य हो जाएगा।

 ./linter check -verbose -pluginPath=./linterPlugin.so bytes debug: appendCombine: disabled by tags (-disableTags) debug: boolExprSimplify: disabled by tags (-disableTags) debug: builtinShadow: disabled by tags (-disableTags) debug: commentedOutCode: disabled by tags (-disableTags) debug: deprecatedComment: disabled by tags (-disableTags) debug: docStub: disabled by tags (-disableTags) debug: emptyFallthrough: disabled by tags (-disableTags) debug: hugeParam: disabled by tags (-disableTags) debug: importShadow: disabled by tags (-disableTags) debug: indexAlloc: disabled by tags (-disableTags) debug: methodExprCall: disabled by tags (-disableTags) debug: nilValReturn: disabled by tags (-disableTags) debug: paramTypeCombine: disabled by tags (-disableTags) debug: rangeExprCopy: disabled by tags (-disableTags) debug: rangeValCopy: disabled by tags (-disableTags) debug: sloppyReassign: disabled by tags (-disableTags) debug: typeUnparen: disabled by tags (-disableTags) debug: unlabelStmt: disabled by tags (-disableTags) debug: wrapperFunc: disabled by tags (-disableTags) debug: appendAssign is enabled debug: assignOp is enabled debug: captLocal is enabled debug: caseOrder is enabled debug: defaultCaseOrder is enabled debug: dupArg is enabled debug: dupBranchBody is enabled debug: dupCase is enabled debug: dupSubExpr is enabled debug: elseif is enabled debug: flagDeref is enabled debug: ifElseChain is enabled debug: panicNil is enabled debug: regexpMust is enabled debug: singleCaseSwitch is enabled debug: sloppyLen is enabled debug: switchTrue is enabled debug: typeSwitchVar is enabled debug: underef is enabled debug: unlambda is enabled debug: unslice is enabled # ...   .

गोमेटालीनट और गोलंगसी-लिंट के साथ तुलना

भ्रम से बचने के लिए, यह परियोजनाओं के बीच मुख्य अंतर का वर्णन करने योग्य है।

gometalinter और golangci-lint मुख्य रूप से अन्य को एकीकृत करते हैं, अक्सर बहुत अलग तरह से कार्यान्वित किए जाते हैं, लिंटर, उन्हें सुविधाजनक पहुंच प्रदान करते हैं। वे अंतिम उपयोगकर्ताओं को लक्षित करते हैं जो स्थैतिक विश्लेषक का उपयोग करेंगे।

लिंटपैक नए लिंटर्स के निर्माण को सरल करता है, एक फ्रेमवर्क प्रदान करता है जो विभिन्न पैकेज बनाता है, इसके आधार पर कार्यान्वित किया जाता है, एक ही निष्पादन फ़ाइल के भीतर संगत होता है। ये जाँचें (गोलंग्सी-लिंट के लिए) या निष्पादन योग्य फ़ाइल (गोमेटालिन्टर के लिए) को फिर पूर्वोक्त मेटा-लिंटर में एम्बेड किया जा सकता है।

मान लीजिए कि golangci-lint संगत चेक golangci-lint का हिस्सा है। यदि इसकी उपयोगिता से संबंधित कोई समस्या है, तो यह golangci-lint की जिम्मेदारी हो सकती है, लेकिन यदि यह स्वयं सत्यापन को लागू करने में कोई गलती है, तो यह सत्यापन के लेखकों की समस्या है, लिंटपेक पारिस्थितिक तंत्र।

दूसरे शब्दों में, ये परियोजनाएँ विभिन्न समस्याओं का समाधान करती हैं।

गो-आलोचक के बारे में क्या?

go-critic को lintpack में पोर्ट करने की प्रक्रिया पहले ही पूरी हो चुकी है, चेकर्स को गो-आलोचक / चेकर्स रिपॉजिटरी में पाया जा सकता है।

 #  go-critic : go get -v github.com/go-critic/go-critic/... #  go-critic : lintpack -o gocritic github.com/go-critic/go-critic/checkers

golangci-lint बाहर go-critic का उपयोग करना थोड़ा समझ में आता है, लेकिन lintpack आपको उन चेकों को स्थापित करने की अनुमति दे सकता है जो go-critic में शामिल नहीं हैं। उदाहरण के लिए, ये आपके द्वारा लिखित निदान हो सकते हैं।

जारी रखा जाए

आप सीखेंगे कि अगले लेख में अपना lintpack संगत चेक कैसे बनाया lintpack ।

वहां हम विश्लेषण करेंगे कि स्क्रैच से कार्यान्वयन की तुलना में अपने लिंटपैक-आधारित lintpack को लागू करने पर आपको क्या फायदे मिलते हैं।

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

लिंटपैक जाओ: कंपोजिट लिंटर मैनेजर