😻 🧟 🎗️ Pylint: कोड विश्लेषक का एक विस्तृत परीक्षण 🤳🏽 💇🏻 👨‍👧

जब ल्यूक ने फ्लेक 8 के साथ काम किया और पाइलिंट पर नज़र रखी, तो उन्हें आभास हुआ कि पाइलिंट द्वारा उत्पन्न 95% गलतियाँ झूठी थीं। अन्य डेवलपर्स को इन विश्लेषणकर्ताओं के साथ अलग-अलग अनुभव थे, इसलिए ल्यूक ने स्थिति पर विस्तार से गौर करने और अपने कोड की 11 हजार लाइनों पर अपने काम का अध्ययन करने का फैसला किया। इसके अलावा, उन्होंने पाइलिंट के लाभों की प्रशंसा की, इसे फ्लेक 8 के अतिरिक्त के रूप में देखा।

ल्यूक ( ल्यूक प्लांट ) - ब्रिटिश डेवलपर्स में से एक, जिनके लेख पर लोकप्रिय कोड विश्लेषक के विश्लेषण के साथ हम हाल ही में आए थे। लिंटर कोड का अध्ययन करते हैं, आपको बग ढूंढने में मदद करते हैं, और इसे स्टाइलिस्टिक रूप से मानकों और कोड के अनुरूप बनाते हैं जो आपकी टीम के डेवलपर्स लिखते हैं। सबसे आम हैं Pylint और Flake8। हम लीडर-आईडी में हैंहम उनका उपयोग भी करते हैं, इसलिए हमने खुशी-खुशी उनके लेख का अनुवाद किया। हमें उम्मीद है कि यह इन उपकरणों के साथ आपके अनुभव को समृद्ध करेगा।

प्रारंभिक सेटिंग्स और परीक्षण आधार

इस प्रयोग के लिए, मैंने अपनी एक परियोजना के कोड का हिस्सा लिया और मूल सेटिंग्स के साथ पाइलिंट को लॉन्च किया। तब उन्होंने परिणाम का विश्लेषण करने की कोशिश की: कौन सी चेतावनी उपयोगी थी और जो झूठी थीं।

उस परियोजना के बारे में थोड़ी मदद जिससे कोड लिया गया था:

Django में लिखा गया एक नियमित अनुप्रयोग (यानी एक ही पायथन के अंदर)। Django की अपनी विशिष्टताएं हैं, और, एक रूपरेखा के रूप में, इसकी अपनी सीमाएं हैं, लेकिन आपको सामान्य पायथन कोड लिखने की अनुमति देता है। अन्य लाइब्रेरीज़ जो टेम्प्लेट्स का उपयोग करती हैं (कॉलबैक फ़ंक्शंस या टेम्प्लेट मेथड डिज़ाइन टेम्प्लेट्स) में इसकी कुछ कमियां भी हैं।
कोड की 22,000 लाइनों से मिलकर बनता है। लगभग 11,000 पंक्तियाँ पाइलिंट (9,000 अगर चूक छोड़ दी गई) से होकर गुज़रीं। परियोजना के इस भाग में मुख्य रूप से विचार और परीक्षण कोड शामिल थे।
इस परियोजना के लिए कोड का विश्लेषण करने के लिए, मैंने पहले से ही Flake8 का उपयोग किया है, प्राप्त सभी त्रुटियों को संसाधित किया है। इस प्रयोग का उद्देश्य फ्लेक 8 के अतिरिक्त पाइलिंट के लाभों का मूल्यांकन करना था।
परियोजना में कोड का एक अच्छा परीक्षण कवरेज है, लेकिन जब से मैं इसका एकमात्र लेखक हूं, मुझे सहकर्मी समीक्षा का उपयोग करने का अवसर नहीं मिला।

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

तो, Pylint ने मेरे कोड के लिए 1650 दावे जारी किए हैं।

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

कीड़े

Pylint को मेरे कोड में ठीक एक बग मिला। मैं बग को एक त्रुटि के रूप में मानता हूं जो प्रोग्राम के संचालन के दौरान उत्पन्न होती है या हो सकती है। इस मामले में, मैंने अपवादों का उपयोग किया - broad-except.यही except Exceptionनहीं, केवल अपवाद को छोड़कर, जो फ्लेके 8 पकड़ता है। यह कुछ अपवादों के साथ रनटाइम व्यवहार के परिणामस्वरूप होगा। यदि यह त्रुटि कभी रन टाइम पर पॉप अप हुई है (यह तथ्य नहीं कि यह पॉप अप है), तो गलत कोड व्यवहार के गंभीर परिणाम नहीं होंगे, हालांकि ...

कुल: 1

उपयोगी

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

उनमें से सात too-many-locals/ too-many-branches/ थे too-many-local-variables। वे मेरे कोड के तीन हिस्सों से संबंधित थे जो खराब संरचित थे। संरचना के बारे में सोचना अच्छा होगा, और मुझे यकीन है कि मैं बेहतर कर सकता था।

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

unused-argument× 3 - उनमें से एक वास्तव में एक जाम था, और कोड को सही ढंग से बेतरतीब ढंग से निष्पादित किया गया था। अन्य दो अनावश्यक और अप्रयुक्त तर्क भविष्य में समस्याओं का कारण बनेंगे यदि मैंने उनका उपयोग किया।
redefined-builtin × २
dangerous-default-value × 2 - बग नहीं, क्योंकि मैंने कभी भी डिफ़ॉल्ट मानों का उपयोग नहीं किया, लेकिन यह सिर्फ मामले में इसे ठीक करना अच्छा होगा।
stop-iteration-return × 1 - यहाँ मैंने अपने लिए कुछ नया सीखा है, मुझे यह कभी नहीं मिला।
no-self-argument × १

कुल: 16

कॉस्मेटिक संपादन

मैं इन बातों पर कम ध्यान दूंगा। वे या तो महत्वहीन हैं या असंभाव्य हैं। दूसरी ओर, उनका सुधार अतिश्योक्तिपूर्ण नहीं होगा। उनमें से कुछ विवादास्पद शैलीगत हैं। मैंने अन्य खंडों में कुछ इसी तरह के जाम के बारे में बात की थी, लेकिन जो यहां सूचीबद्ध हैं, वे इस संदर्भ में भी उपयुक्त हैं। Pylint का नियमित रूप से उपयोग करते हुए, मैं इन "खामियों" को ठीक करूंगा, लेकिन ज्यादातर मामलों में मैं उनके बारे में चिंता नहीं करूंगा।

invalid-name× 192

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

या

कई परीक्षण कोड में थे:

len-as-condition × 20
useless-object-inheritance × 16 (पायथन 2 विरासत)
no-else-return × ११
no-else-raise × १
bad-continuation × ६
redefined-builtin × ४
inconsistent-return-statements × १
consider-using-set-comprehension × १
chained-comparison × १

कुल: 252

निकम्मा

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

too-many-ancestors × 76६

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

unused-variable × ४३

यह लगभग हर समय परीक्षण कोड में पाया गया, जहां मैंने रिकॉर्ड तोड़ा:

... और किसी भी तत्व का उपयोग नहीं किया। पाइलिंट को रिपोर्टिंग त्रुटियों से रोकने के कई तरीके हैं (उदाहरण के लिए, नाम दें unused)। लेकिन अगर आप इसे उस रूप में छोड़ देते हैं जिसमें मैंने लिखा है, तो यह पठनीय होगा, और लोग (स्वयं सहित) इसे समझने और समर्थन करने में सक्षम होंगे।

invalid-name × 26

ये ऐसे मामले थे जहां मैंने संदर्भ में उपयुक्त नाम दिए थे, लेकिन जो लोग पाइलिन नामकरण मानकों को पूरा नहीं करते थे। उदाहरण के लिए, db (यह डेटाबेस के लिए एक सामान्य संक्षिप्त नाम है) और कुछ अन्य गैर-मानक नाम, जो, मेरी राय में, अधिक समझने योग्य थे। लेकिन आप मुझसे सहमत नहीं हो सकते।

redefined-outer-name × 16

कभी-कभी एक चर नाम को आंतरिक और बाहरी दोनों संदर्भों के लिए सही ढंग से लिखा जाता है। और आपको आंतरिक संदर्भ से बाहरी नाम का उपयोग कभी नहीं करना होगा।

too-few-public-methods × 14

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

no-self-use × १२

वे परीक्षण कोड में उत्पन्न हुए, जहां मैंने जानबूझकर बिना पैरामीटर के आधार वर्ग के तरीकों को जोड़ा self, क्योंकि इस तरह उन्हें आयात करना और उन्हें परीक्षण के मामले के लिए उपलब्ध कराना अधिक सुविधाजनक था। उनमें से कुछ भी अलग-अलग कार्यों में लिपटे हुए थे।

attribute-defined-outside-init × 10

इन मामलों में, कोड लिखने के अच्छे कारण थे जैसा कि यह है। असल में, परीक्षण कोड में ये त्रुटियां हुईं।

too-many-locals× 6, too-many-return-statements× 6, too-many-branches× 2, too-many-statements× 2

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

arguments-differ × ६

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

ungrouped-imports × ४

मैं पहले से ही आयात करने के लिए isort का उपयोग करता हूं

fixme × ४

हां, कई चीजें हैं जिन्हें ठीक करने की आवश्यकता है, लेकिन अभी मैं उन्हें ठीक नहीं करना चाहता।

duplicate-code × ३

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

broad-except × २
abstract-method × २
redefined-builtin × २
too-many-lines × १

मैंने इस मॉड्यूल को तोड़ने के लिए किस प्राकृतिक तरीके से यह पता लगाने की कोशिश की, लेकिन नहीं कर सका। यह एक उदाहरण है जहां आप देख सकते हैं कि लिंटर गलत उपकरण है। यदि मेरे पास कोड की 980 लाइनों के साथ एक मॉड्यूल है, और मैं एक और 30 जोड़ता हूं, तो मैं 1000 लाइनों की सीमा को पार करता हूं, और लिंटर से सूचनाएं यहां मेरी मदद नहीं करेंगी। यदि 980 लाइनें ठीक हैं, तो 1010 खराब क्यों है? मैं इस मॉड्यूल को रिफलेक्टर नहीं करना चाहता, लेकिन मैं चाहता हूं कि लिंटर त्रुटियों का उत्पादन न करे। इस समय मैं जो एकमात्र समाधान देख रहा हूं वह यह है कि लिंटर को चुप करा दिया जाए, और यह अंतिम लक्ष्य का खंडन करता है।

pointless-statement × १
expression-not-assigned × १
cyclic-import × १

हमने इसके फंक्शन्स को एक फंक्शन में ले जाकर साइकल का पता लगाया। मुझे प्रतिबंधों के आधार पर कोड की संरचना के लिए एक बेहतर तरीका नहीं मिला।

unused-import × १

मैंने पहले से ही # NOQAFlake8 का उपयोग करते समय जोड़ा था ताकि यह त्रुटि पॉप न हो।

too-many-public-methods × १

यदि मेरे परीक्षण वर्ग में 20 विनियमित लोगों के बजाय 35 परीक्षण हैं, तो क्या यह वास्तव में एक समस्या है?

too-many-arguments × १

कुल: 243

ठीक करने में असमर्थ

यह श्रेणी उन त्रुटियों को दर्शाती है, जो बाहरी प्रतिबंधों के कारण मैं चाहकर भी ठीक नहीं कर पा रहा हूं, जैसे कि किसी तृतीय-पक्ष लाइब्रेरी या ढांचे में कक्षाओं को वापस करने या पास करने की आवश्यकता जो कि कुछ आवश्यकताओं को पूरा करना चाहिए।

unused-argument × 21
invalid-name × 13
protected-access × ३

"डॉक्युमेंटेड इंटरनल ऑब्जेक्ट्स" तक पहुंच शामिल है, जैसे कि sys._getframeस्टडलिब और Django में Model._meta।

too-few-public-methods × ३
too-many-arguments × २
wrong-import-position × २
attribute-defined-outside-init × १
too-many-ancestors × १

कुल: 46

गलत संदेश

जिन चीजों में पाइलिंट स्पष्ट रूप से गलत है। इस मामले में, ये Pylint त्रुटियाँ नहीं हैं: तथ्य यह है कि पायथन गतिशील है, और Pylint उन चीजों की खोज करने की कोशिश कर रहा है जो पूरी तरह से या मज़बूती से नहीं की जा सकती हैं।

no-member × 395

कई बेस कक्षाओं के साथ जुड़े: Django और उन लोगों से जिन्हें मैंने खुद बनाया था। पाइलिंट गतिशीलता / मेटाप्रोग्रामिंग के कारण चर का पता नहीं लगा सका।

परीक्षण कोड की संरचना के कारण कई त्रुटियां हुईं (मैंने django-functionalest से एक टेम्पलेट का उपयोग किया, जिसे कुछ मामलों में "अमूर्त" विधियों का उपयोग करके अतिरिक्त आधार वर्गों को जोड़कर सुधारा जा सकता है NotImplementedError) या, संभवतः, कई परीक्षण कक्षाओं का नाम बदलकर (I मैंने ऐसा नहीं किया, क्योंकि कुछ मामलों में यह भ्रामक होगा)।

invalid-name × ५२

समस्या मुख्य रूप से उत्पन्न हुई क्योंकि पाइल्ट ने पीईपी 8 निरंतर नियम को लागू किया , यह देखते हुए कि प्रत्येक शीर्ष-स्तरीय नाम ="स्थिर" है। वास्तव में एक निरंतरता से हमारा मतलब परिभाषित करना जितना मुश्किल लगता है उससे कहीं अधिक कठिन है, लेकिन यह कुछ चीजों पर लागू नहीं होता है जो स्वाभाविक रूप से स्थिर हैं, उदाहरण के लिए, कार्य। इसके अलावा, नियम कार्यों को बनाने के कम परिचित तरीकों पर लागू नहीं किया जाना चाहिए, उदाहरण के लिए:

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

no-self-use × 23

पाइलिंट ने गलत तरीके से कहा कि विधि कई मामलों के लिए एक फ़ंक्शन हो सकती है जहां मैं विभिन्न कार्यान्वयन करने के लिए विरासत का उपयोग करता हूं, क्रमशः, मैं उन्हें कार्यों में परिवर्तित नहीं कर सकता।

protected-access × ५

Pylint ने गलत तरीके से मूल्यांकन किया कि कौन "स्वामी" था (वर्तमान कोड टुकड़ा ऑब्जेक्ट की संरक्षित विशेषता बनाता है और स्थानीय रूप से इसका उपयोग करता है, लेकिन Pylint यह नहीं देखता है)।

no-name-in-module × १
import-error × १
pointless-statement × १

इस कथन ने वास्तव में परिणाम उत्पन्न किया:

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

कुल: 477

उप-योग

हम अभी फिनिश लाइन पर नहीं हैं, लेकिन हमारे परिणामों को समूहित करने का समय है:

"गुड" - "बग्स" और "यूटिलिटीज" ब्लॉक - यहाँ पाइलिंट ने निश्चित रूप से मदद की: 17।
"तटस्थ" - "कॉस्मेटिक परिवर्तन" - पाइलिंट से मामूली लाभ, त्रुटियों से नुकसान नहीं होगा: 252।
"बुरा" - "बेकार", "ठीक करने में असमर्थ", "अशुद्धि" - जहां पाइल्ट कोड में बदलाव चाहता है, जहां इसकी आवश्यकता नहीं है। जिसमें बाहरी निर्भरता के कारण संपादन नहीं किया जा सकता है या जहां Pylint ने गलत तरीके से कोड का विश्लेषण किया है: 766।

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

झूठी सूचनाओं को हटाने के लिए, आप आउटगोइंग एरर क्लास (जो तब पाइलिंट का उपयोग करने की बेकारता को बढ़ाएंगे) को डुबो सकते हैं या कोड में विशेष टिप्पणी जोड़ सकते हैं । मैं बाद में नहीं करना चाहता, क्योंकि:

इसमें समय लगता है!
मुझे उन टिप्पणियों का ढेर पसंद नहीं है जो लिंटर को चुप कराने के लिए मौजूद हैं।

मैं ख़ुशी से इन छद्म टिप्पणियों को जोड़ूंगा जब लिंटर से एक निश्चित प्लस होगा। इसके अलावा, मैं टिप्पणियों के बारे में चिंतित हूं, इसलिए मेरा सिंटैक्स हाइलाइटिंग उन्हें विशद रूप से प्रदर्शित करता है: जैसा कि इस लेख में अनुशंसित है । हालाँकि, कुछ स्थानों पर मैंने पहले ही NOQAFlake8 को मिटाने के लिए # टिप्पणियां जोड़ दी हैं, लेकिन उनके साथ एक सेक्शन के लिए आप केवल पाँच त्रुटि कोड जोड़ सकते हैं।

Docstrings

Pylint की खोज की गई शेष समस्याएं दस्तावेजीकरण रेखाएँ नहीं थीं। मैंने उन्हें एक अलग श्रेणी में रखा क्योंकि:

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

कुल मिलाकर, पाइलिंट ने 620 लापता डॉकस्ट्रिंग्स (मॉड्यूल, फ़ंक्शंस, क्लास मेथड्स) की खोज की। लेकिन कई मामलों में, मैं सही था। उदाहरण के लिए:

जब नाम से सब कुछ स्पष्ट हो। उदाहरण के लिए:
जब एक डॉकस्ट्रिंग पहले से ही परिभाषित है - उदाहरण के लिए, अगर मैं Django के डेटाबेस राउटर इंटरफ़ेस को लागू करता हूं । इस मामले में अपनी खुद की लाइन जोड़ना खतरनाक हो सकता है।

अन्य मामलों में, वर्णन की इन पंक्तियों से मेरे कोड को नुकसान नहीं होगा। पाइलिंट को मिले लगभग 15 से 30% मामलों में, मैंने सोचा होगा, "हां, मुझे यहां एक डॉकस्ट्रिंग जोड़ने की जरूरत है, रिमाइंडर के लिए पाइलिंट का धन्यवाद।"

सामान्य तौर पर, मैं उन उपकरणों की तरह नहीं हूं जो हर जगह और हर जगह डॉकिंग जोड़ते हैं, क्योंकि मुझे लगता है कि इस मामले में वे बहुत खराब हो जाएंगे। उन्हें लिखना बिल्कुल बेहतर नहीं है। खराब टिप्पणियों के साथ एक समान स्थिति:

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

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

निष्कर्ष

मेरा मानना है कि Pylint की बेकारता के बारे में मेरी शुरुआती धारणा सही निकली (कोड आधार के संदर्भ में जिसके लिए मैं Flake8 का उपयोग करता हूं)। मेरे लिए इसका उपयोग करने के लिए, झूठी सकारात्मक की संख्या को दर्शाने वाला सूचक कम होना चाहिए।

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

अगर आप किसी प्रोजेक्ट में पाइलिंट का इस्तेमाल शुरू से ही कर रहे हैं या ऐसे प्रोजेक्ट में जहां कोई बाहरी निर्भरता नहीं है, तो मुझे लगता है कि आपकी अलग राय होगी और झूठी नोटिफिकेशन की संख्या कम होगी। हालांकि, इससे अतिरिक्त समय की लागत हो सकती है।

एक अन्य दृष्टिकोण है कि सीमित संख्या में त्रुटियों के लिए पाइलिंट का उपयोग करना। हालाँकि, केवल कुछ ही थे, जिन पर प्रतिक्रियाएँ सही या अत्यंत दुर्लभ थीं (सापेक्ष और निरपेक्ष शब्दों में)। उनमें से हैं: dangerous-default-value, stop-iteration-return, broad-exception, useless-object-inheritance।

किसी भी मामले में, मुझे आशा है कि इस लेख ने आपको यह विचार करने में मदद की कि क्या पाइलिंट का उपयोग करना है या सहयोगियों के साथ विवाद में।

Pylint: कोड विश्लेषक का एक विस्तृत परीक्षण