लिंटर के बारे में होलीवर्नी की कहानी

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

लिंटर एक शैली में कोड लाने और गलतियों से बचने में मदद करते हैं। सच है, केवल अगर आप दुख के लिए तैयार हैं, और अंत में खारिज न करें "pylint: अक्षम", केवल इसे पीछे करने के लिए। लिंटर क्या होना चाहिए, और पाइलिंट ऐसा क्यों नहीं कर सकता, निकिता सोबोलेवन को जानता है, जो लिंटर को इतना समझता और प्यार करता है कि उसने अपनी कंपनी का नाम भी ऐसा रखा, ताकि उन्हें परेशान न किया जाए - wemake.services।



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

हमें लिंटर की आवश्यकता क्यों है?

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

लिंटर एक समीक्षा पर जीवन को आसान बनाते हैं । मैं कोड की समीक्षा करने के लिए आता हूं और सोचता हूं: “मैं ऐसा नहीं करना चाहता हूं! अब अतिरिक्त स्थान और अन्य बकवास होंगे! ” मैं चाहूंगा कि कोई और अच्छा कोड तैयार करे, और उसके बाद मैं महान वैचारिक चीजों की सराहना करूंगा।

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

लिंटर क्या हैं?

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

लिंटर का उपयोग कैसे करें?

मैं यह दावा नहीं करता कि लिंटर एक रामबाण और हर चीज के लिए एक प्रतिस्थापन है। ऐसा नहीं है। लाइनर - पिरामिड का पहला चरण, जिसके द्वारा कोड उत्पादन में मिलता है।

पिरामिड में तीन चरण हैं:

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

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

क्या आप काम में एक लाइनर का उपयोग करते हैं?

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

कोड समीक्षा

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

डिफ़ॉल्ट रूप से, प्रक्रिया इस तरह दिखती है: कोड एक समीक्षा के लिए आता है, मुझे त्रुटियां मिलती हैं, और मैं उन्हें अब और नहीं बनाना चाहता। उदाहरण के लिए, मैंने देखा कि डेवलपर ने BaseException को पकड़ा: “ऐसा मत करो। कृपया पकड़ नहीं है! " 10 दिन बाद फिर वही बात। मैं आपको फिर से याद दिलाता हूं:

- हम BaseException को नहीं पकड़ते हैं।
" अच्छा, मैं समझ गया।"

एक साल बीत जाता है - वही गलती। एक नया आदमी आता है - वही गलती। मुझे लगता है - हम सब कुछ कैसे स्वचालित कर सकते हैं ताकि स्थिति फिर से न हो, और केवल दिमाग में आता है: “ चलो हमारे लिंटर को मारना है? »चलो एक खुला पैकेज बनाते हैं, वहाँ सभी नियमों का उपयोग करते हैं जो हम काम में लेते हैं और नियमों की जांच स्वचालित करते हैं ताकि हर बार हम हाथ से न लिखें। हम सब कुछ अच्छी तरह से और तुरंत स्वचालित करते हैं!

स्वाभाविक रूप से, आप कह सकते हैं: " तैयार किए गए लिंटर पहले से ही मौजूद हैं, वे काम करते हैं, हर कोई उनका उपयोग करता है - वे अपना क्यों करते हैं?", और आप बिल्कुल सही होंगे, क्योंकि वास्तव में लिंटर हैं। आइए देखें कि कौन से हैं और वे क्या करते हैं।

Pylint

शीर्ष पर " क्यों नहीं Pylint?" “मैंने यह सवाल कई बार सुना है। मैं उसे नरम जवाब दूंगा। पाइलिंट पायथन कोड के लिए एक महान रॉक स्टार उपकरण है, लेकिन इसमें ऐसी विशेषताएं हैं जो मैं अपने लिंटर में नहीं देखना चाहता।

यह सब कुछ एक साथ मिलाता है: शैलीगत जाँच, सर्वोत्तम अभ्यास और प्रकार जाँच । पाइलिंट प्रकार की जाँच अविकसित है क्योंकि किसी प्रकार की जानकारी नहीं है: यह किसी तरह इसे प्रदर्शित करने की कोशिश करता है, लेकिन यह बहुत अच्छी तरह से काम नहीं करता है। इसलिए, अक्सर जब मैं Django पर model_name.some_property लिखता model_name.some_property , तो मैं त्रुटि देख सकता हूं: "क्षमा करें, ऐसी कोई संपत्ति नहीं है - आप इसका उपयोग नहीं कर सकते हैं!" मुझे याद है कि एक प्लगइन है, मैं इसे स्थापित करता हूं, फिर मैं सेलेरी का उपयोग करता हूं, यह किसी प्रकार की परेशानी भी शुरू करता है, मैं सेलेरी के लिए प्लगइन स्थापित करता हूं, कुछ अन्य जादू पुस्तकालय का उपयोग करता हूं, और नतीजतन, मैं हर जगह लिखता हूं: "पाइलिंट: अक्षम ... यह नहीं है कि लिंटर से मुझे क्या चाहिए।

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

पाइलिंट के अलावा, अन्य लिंटर हैं जो अपना काम भी करते हैं।

SonarQube

एक अद्भुत, लेकिन एक अलग उपकरण जो आपके प्रोजेक्ट के करीब रहता है।

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

सोनारक्यूब को विकसित करने वाली कंपनी विशेष रूप से उत्पाद विकास की अवधारणा को देखती है। यह एक समस्या हो सकती है।

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

Flake8

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

दुनिया में सबसे कठोर लिंटर

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

हमारे लिंटर में मुख्य शब्द सख्त है, जिसका अर्थ है दर्द और पीड़ा।

यदि आप लिंटर का उपयोग करते हैं, और यह आपको पीड़ित नहीं करता है ताकि आप अपने सिर को जकड़ें: "आप इसे अभी तक पसंद क्यों नहीं करते हैं, तो आपको लानत है," तो यह एक बुरा लिंटर है। यह त्रुटियों को छोड़ देता है, कोड की गुणवत्ता की पर्याप्त निगरानी नहीं करता है, और हमें इसकी आवश्यकता नहीं है। हमें दुनिया में सबसे कड़े की जरूरत है, जो बहुत जांच करता है। अब हमारे पास दोनों श्रेणियों में लगभग 250 अलग-अलग परीक्षण हैं : शैलीगत और सर्वोत्तम अभ्यास, लेकिन बिना प्रकार की जाँच के। Mypy इसमें लगी हुई है, हम किसी भी तरह से उसकी चिंता नहीं करते हैं।

हमारे लिंटर का कोई समझौता नहीं है । हमारे पास "मैं ऐसा नहीं करना चाहता, लेकिन अगर आप वास्तव में करना चाहते हैं, तो श्रेणी से कोई नियम नहीं है, तो आप कर सकते हैं।" नहीं, हम हमेशा कठोर बोलते हैं - हम ऐसा नहीं करते हैं, क्योंकि यह बुरा है। फिर लोग आते हैं और कहते हैं: "2.5 उपयोग मामला है जहां यह सिद्धांत में संभव है!"। यदि ऐसे मामले हैं, तो स्पष्ट रूप से लिखें कि यह लाइन लिंटर के लिए इसे अनदेखा करने की अनुमति है, लेकिन क्यों समझाएं। यह टिप्पणी होनी चाहिए कि आपने कुछ अजीब अभ्यास की अनुमति दी और आप ऐसा क्यों कर रहे हैं। यह दृष्टिकोण दस्तावेजीकरण कोड के लिए भी उपयोगी है।

सबसे कड़े लिंटर को सेटिंग्स (WIP) की आवश्यकता नहीं होती है । हमारे पास अभी भी सेटिंग्स हैं, लेकिन हम उनसे छुटकारा चाहते हैं: स्वतंत्रता होने पर, उपयोगकर्ता निश्चित रूप से कॉन्फ़िगर करेगा ताकि लिंटर सही ढंग से काम न करे।

एक अच्छे टूल को सेटिंग्स की आवश्यकता नहीं है - इसमें अच्छे डिफ़ॉल्ट मान हैं।

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

हम किस पर निर्भर हैं?

बड़ी संख्या में साधनों से।

• परत 8 ।
• Eradicate एक शांत प्लगइन है जो कोड में खंडों पर टिप्पणी करता है और आपको उन्हें हटा देता है, क्योंकि किसी प्रोजेक्ट में मृत कोड संग्रहीत करना खराब है। हमें ऐसा करने की अनुमति नहीं है।
• Isort एक उपकरण है जो आपको आयात को सही ढंग से क्रमबद्ध करने के लिए मजबूर करता है: क्रम में, इंडेंटिंग, सुंदर उद्धरण।
• स्टैटिक कोड सिक्योरिटी को स्टेटिकली चेक करने के लिए बैंडिट एक बेहतरीन टूल है। यह वायर्ड पासवर्ड, कोड में Popen , Popen , sys.exit को कॉल करता है और कहता है कि यह सब उपयोग नहीं किया जा सकता है, लेकिन यदि आप चाहते हैं, तो यह कारण लिखने के लिए कहता है।
• और 20 से अधिक प्लगइन्स जो ब्रैकेट, उद्धरण और कॉमा की जांच करते हैं।

हम क्या जाँच कर रहे हैं?

नियमों के 4 समूह हैं जिनका हम उपयोग करते हैं और लागू करते हैं।

जटिलता सबसे बड़ी समस्या है। हमें नहीं पता कि जटिलता क्या है और हम इसे कोड में नहीं देखते हैं। हम उस कोड को देखते हैं जिसके साथ हम हर दिन काम करते हैं और ऐसा लगता है कि यह जटिल नहीं है - इसे लें, इसे पढ़ें, सब कुछ काम करता है। ऐसा नहीं है। सरल कोड एक परिचित कोड है। जटिलता के स्पष्ट मानदंड हैं जो हम परीक्षण करते हैं। स्वयं मानदंडों के बारे में - बाद में। यदि कोड मानदंड का उल्लंघन करता है, तो हम कहते हैं: "कोड जटिल है, फिर से लिखना!"

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

स्थिरता के लिए , हमारे पास एक सरल नियम है - हर जगह एक ही लिखें। यदि कोई अनुमोदित दृष्टिकोण है, तो हर जगह इसका उपयोग करें। इससे कोई फर्क नहीं पड़ता कि आप इसे पसंद करते हैं या नहीं, संगति अधिक महत्वपूर्ण है।

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

जटिलता क्या है?

जटिलता में विशिष्ट मीट्रिक हैं जो आप देख सकते हैं और कह सकते हैं कि यह मुश्किल है या नहीं। उनमें से बहुत सारे हैं।

साइक्लोमैटिक जटिलता - हर किसी की पसंदीदा साइक्लोमैटिक जटिलता। यह कोड में बड़ी संख्या में नेस्टेड के for , अन्य संरचनाओं के लिए, और कोड की बहुत अधिक शाखा और पढ़ने में कठिनाई को इंगित करता है। एम्बेडेड कोड के साथ सब कुछ खराब है: आप पढ़ते हैं, पढ़ते हैं, पढ़ते हैं - वापस चले गए, पढ़ें, पढ़ें, पढ़ें - कूद गए, फिर दूसरे चक्र में। ऊपर से नीचे तक ऐसे कोड को सुरक्षित रूप से पारित करना असंभव है।

तर्क, कथन और विवरण। ये मात्रात्मक मीट्रिक हैं: फ़ंक्शन या विधि में कितने तर्क हैं, कितने इस फ़ंक्शन के शरीर के अंदर हैं या कथन और रिटर्न विधि।

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

जोन्स जटिलता - मैंने इस मीट्रिक को उधार लिया, लेकिन केवल इसलिए कि यह एक बम है! जोन्स कॉम्प्लेक्सिटी एक लाइन की जटिलता को निर्धारित करती है - लाइन जितनी जटिल होती है, इसे समझना उतना ही मुश्किल होता है, क्योंकि अल्पकालिक मानव मेमोरी एक बार में 5-9 से अधिक ऑब्जेक्ट प्रोसेस नहीं कर सकती है। यह तथाकथित मिलर का बटुआ है ।

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

झरना कठिनाई

कठिनाई इस तथ्य से शुरू होती है कि हमने लाइन लिखी थी, और यह अभी भी अच्छा है। लेकिन फिर व्यापार आता है और कहता है कि कीमतें दोगुनी हो गई हैं, और हम 2 से गुणा करते हैं। इस बिंदु पर, जोन्स कॉम्प्लेक्सिटी पागल हो जाती है और रिपोर्ट करती है कि अब लाइन बहुत जटिल है - बहुत अधिक तर्क है।

खैर, हम एक नया चर शुरू करते हैं, और फ़ंक्शन जटिलता विश्लेषक कहते हैं:

- नहीं, ऐसा नहीं है - अब फ़ंक्शन के अंदर बहुत सारे चर हैं।

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

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

"रिफ्लेक्टर की आवश्यकता है" - यह चीज आपको कोड को रिफलेक्टर बनाती है। आप बस वापस नहीं बैठ सकते: "मैं इस कोड को नहीं छूता, यह काम करने लगता है।" नहीं, एक दिन आप कोड को कहीं और बदल देंगे, और जटिलता का एक झरना उस मॉड्यूल को भर देगा जो आपने स्पर्श नहीं किया था और आपको इसे फिर से भरना होगा। मेरा मानना ​​है कि रीफैक्टरिंग अच्छी है, और यह जितना अधिक है, उतना ही अधिक स्थिर और बेहतर आपका सिस्टम काम करता है। और सब कुछ व्यक्तिपरक है!

अब बात करते हैं स्वाद की। यह एक समग्र और इंटरैक्टिव हिस्सा है!

holivar

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

नाम

आपको कैसा लगा: var, value, item, obj, data, result ? डेटा क्या है? कुछ डेटा। परिणाम क्या है? किसी प्रकार का परिणाम। अक्सर मुझे परिणामी चर और एक असंगत कक्षा में कुछ हीन विधि के लिए एक कॉल दिखाई देता है - और मुझे लगता है: "यह परिणाम क्या है? वह यहाँ क्यों है? ”

ऐसे कई डेवलपर हैं जो मुझसे असहमत हैं और कहते हैं कि मूल्य बिल्कुल सामान्य चर नाम है:

- मैं हमेशा कुंजी और मूल्य का उपयोग करता हूं!
- कुंजी और मूल्य का उपयोग क्यों नहीं करते हैं, लेकिन कहते हैं कि कुंजी नाम और मूल्य अंतिम नाम है? First_name और last_name को नाम देना असंभव क्यों है - अब एक संदर्भ है।

आमतौर पर लोग सहमत होते हैं, लेकिन वे वैसे भी बहस करते हैं। यह बहुत ही समग्र बात है: कम से कम 3 लोगों ने अपने जीवन का एक घंटा मेरे साथ इस बारे में बहस करने के लिए बिताया।

क्या एक अक्षर के साथ चर नाम देना ठीक है?

उदाहरण के लिए, क्यू ? हम सभी को क्लासिक केस पता है: for i in some_iterable: मैं क्या हूँ ? सी में, यह मानक अभ्यास है, और इससे सब कुछ आता है। लेकिन पायथन में, संग्रह और पुनरावृत्तियों। संग्रह में ऐसे तत्व हैं जिनके नाम हैं - चलो उन्हें किसी तरह अलग तरह से बुलाते हैं।

आधे डेवलपर्स को लगता है कि वैरिएबल i, x, y, z को कॉल करना सामान्य है।

मेरा मानना ​​है कि आप एक अक्षर से नाम नहीं बता सकते। मैं अधिक संदर्भ चाहता हूं और यह अच्छा है कि डेवलपर्स की दूसरी छमाही मुझसे सहमत है। यदि सी में यह ऐतिहासिक विरासत के कारण अभी भी किसी तरह स्वीकार्य है, तो पायथन में यह एक बहुत बड़ी समस्या है और आपको ऐसा करने की आवश्यकता नहीं है।

संगति

चलो बस कई में से एक रास्ता चुनते हैं, और कहते हैं, "चलो करते हैं।" चाहे वह अच्छा हो या बुरा - इससे कोई फर्क नहीं पड़ता - बस संगत है।

हम केवल पायथन 3 के बारे में बात कर रहे हैं, लिगेसी को बिल्कुल नहीं माना जाता है।

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

यदि Class Some(object) या Class Some(object) लिखने का विकल्प है, तो मैं पहले वाले को चुनूंगा। एक तरफ, यह दर्शाता है कि हम हमेशा स्पष्ट रूप से लिखते हैं कि हमें क्या विरासत में मिला है। दूसरी ओर, इसमें कोई विशेष क्रिया नहीं है : हम कुछ अतिरिक्त कीस्ट्रोक्स से कुछ भी नहीं खोते हैं।

दो-तिहाई डेवलपर्स दूसरे विकल्प से अधिक परिचित हैं, और मुझे भी पता है कि क्यों। मेरी परिकल्पना: सभी क्योंकि हम लंबे समय से पायथन के दूसरे संस्करण से तीसरे में चले गए हैं, और अब हम दिखाते हैं कि हम तीसरे पायथन में लिख रहे हैं। मुझे नहीं पता कि परिकल्पना कैसे सही है, लेकिन मुझे ऐसा लगता है।

F- लाइनें भयानक हैं?

उत्तर विकल्प:

• हां: वे संदर्भ खो देते हैं, टेम्पलेट में तर्क डालते हैं और लिंट नहीं करते हैं - (38%)।
• नहीं! वे एक चमत्कार हैं! - (62%)।

एक परिकल्पना है कि एफ-लाइनें भयानक हैं। वे उनमें कुछ भी हिलाते हैं! f- लाइनें, .format के समान नहीं हैं, अंतर नाटकीय हैं। जब हम एक टेम्पलेट घोषित करते हैं, और फिर इसे प्रारूपित करते हैं, तो हम दो क्रियाओं को अलग-अलग करते हैं: पहले हम टेम्पलेट को परिभाषित करते हैं, और फिर इसे प्रारूपित करते हैं। जब हम एक एफ-लाइन की घोषणा करते हैं, तो हम एक साथ दो क्रियाएं करते हैं: हम तुरंत टेम्पलेट की घोषणा करते हैं और उसी क्षण इसे प्रारूपित करते हैं।

एफ-लाइन के साथ दो समस्याएं हैं। हमने एफ-लाइन और सब कुछ काम करने के लिए एक टेम्पलेट घोषित किया। और फिर हम टेम्पलेट 2 लाइनों को स्थानांतरित करने या इसे किसी अन्य फ़ंक्शन पर ले जाने का निर्णय लेते हैं - और सब कुछ टूट जाता है। अब कोई संदर्भ नहीं है जो हमें स्ट्रिंग्स को प्रारूपित करने की अनुमति देता है , और हम उन्हें सही तरीके से संसाधित नहीं कर सकते हैं। एफ-लाइनों के साथ दूसरी बड़ी समस्या: वे आपको भयानक काम करने की अनुमति देते हैं - तर्क को टेम्पलेट में चिपका दें । मान लीजिए कि एक पंक्ति है जिसमें हम केवल उपयोगकर्ता नाम और "हैलो" शब्द सम्मिलित करते हैं - यह सामान्य है। विशेष रूप से भयानक कुछ भी नहीं है, लेकिन फिर हम देखते हैं कि उपयोगकर्ता नाम बड़े अक्षरों में आता है, हम इसे एक शीर्षक मामले में अनुवाद करने का निर्णय लेते हैं और सीधे username.title() टेम्पलेट में लिखते हैं। फिर, टेम्पलेट में स्थितियां, चक्र, आयात दिखाई देते हैं। और php के अन्य सभी भागों।

ये सभी समस्याएं मुझे यह कहती हैं कि एफ-लाइन एक बुरा विषय है , हम उनका उपयोग नहीं करते हैं। मजेदार बात यह है कि हमारे पास ऐसा कोई मामला नहीं है जिसमें केवल एफ-लाइन्स हमारे लिए उपयुक्त हों। आमतौर पर कोई भी प्रारूपण उपयुक्त होता है, लेकिन हमने चुना। .format - बाकी सब असंभव है - न तो % , न ही एफ-लाइन्स। .Format का काम लिंट भी किया जाता है, क्योंकि इसके अंदर आप घुंघराले कोट्स लगा सकते हैं और या तो वेरिएबल का नाम या उसका ऑर्डर लिख सकते हैं।

रिपोर्ट के दौरान, एफ-लाइन विरोधियों की संख्या 33 से बढ़कर 38% हो गई - यह एक छोटी, लेकिन जीत है।

संख्या

क्या आप इस तरह की संख्याएँ पसंद करते हैं: final_score = 69 * previous result / 3.14 । यह कोड की एक मानक रेखा की तरह लगता है, लेकिन 69 क्या है? इस तरह के सवाल अक्सर तब आते हैं जब मैं उस कोड को देखता हूं जो मैंने कुछ समय पहले लिखा था, और उस पल में प्रबंधक कहता है:

- कृपया 147 से गुणा करें।
- 147 पर क्यों?
- हमारे पास इस तरह के टैरिफ हैं।

मैं गुणा और भूल गया, या लंबे समय तक मैंने गुणांक का कुछ मूल्य उठाया ताकि सब कुछ काम कर सके - और फिर मैं भूल गया कि मैंने इसे कैसे उठाया और क्यों। यह पता चला है कि एक महत्वपूर्ण संख्या के पीछे महत्वपूर्ण शोध कार्य छिपा हुआ है। मुझे यह भी पता नहीं है कि यह संख्या क्या है, लेकिन मैं बाद में कमिट करके किसी भी तरह इसे ढूंढ सकता हूं, याद कर सकता हूं और पुनर्स्थापित कर सकता हूं।

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

इस प्रकार, हम गारंटी देते हैं कि कोई जादू नंबर हमारे कोड के माध्यम से नहीं मिलेगा और इसे अंदर से जटिल करेगा। वे प्रत्येक पंक्ति की जटिलता की जाँच के माध्यम से अपना रास्ता बनाते हैं और कहते हैं: "यहाँ संख्या 4766 है। यह क्या है, मुझे नहीं पता, इसे अपने आप सुलझाओ!" यह मेरे लिए एक बड़ी खोज थी।

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

लेकिन अपवाद हैं - ये from10 से 10, संख्या 100, 1000 और इसी तरह की संख्याएं हैं, बस क्योंकि वे अक्सर पाए जाते हैं और उनके बिना मुश्किल है। हम कठिन हैं, लेकिन दुखवादी नहीं हैं और थोड़ा सोचते हैं।

क्या आप '@staticmethod' का उपयोग करते हैं?

आइए इस बारे में सोचें कि स्टैटिकमेथोड क्या है । क्या आपने कभी सोचा है कि यह पायथन में क्यों है? मैं नहीं करता। मेरे पास एक सुंदर पाइलिंट था जिसने कहा:

- देखो, तुम self का उपयोग नहीं कर रहे हैं , cls - एक staticmethod करो!
- ठीक है, Pylint, मैं एक staticmethod करूँगा।

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

मैंने प्रश्न को ध्यान में रखा, और यह खरगोश के छेद जितना गहरा निकला। कई अन्य प्रोग्रामिंग लैंग्वेज हैं जिनमें स्टैटिकमेथोड को भी पसंद नहीं किया जाता है। और अच्छी तरह से तर्क दिया गया है - staticmethod ऑब्जेक्ट मॉडल को तोड़ता है। नतीजतन, मुझे एहसास हुआ - स्टेटमिथोड यहां जगह नहीं है , और हमने इसे देखा। अब, यदि हम स्टेटमिथोड डेकोरेटर का उपयोग करते हैं, तो लिंटर कहेगा: "नहीं, क्षमा करें, रिफैक्ट"!

अधिकांश डेवलपर्स मुझसे असहमत हैं, लेकिन लगभग आधे अभी भी सोचते हैं कि स्टैथमेथोड के बजाय नियमित तरीके या नियमित कार्य लिखना बेहतर है।

__Init __ में तर्क। Ru - अच्छा या बुरा?

यह मेरा पसंदीदा विषय है। निश्चित रूप से, जब आप एक नया पैकेज बनाते हैं और किसी तरह इसे कहते हैं - यह __init __ बनाता है। Ru और आप आश्चर्य करते हैं कि इसमें क्या डाला जाए? क्या __init __ में डाल दिया। आरयू, और क्या - पक्ष में फाइलों में? मेरे लिए, यह एक गैर-तुच्छ प्रश्न था, और मैं हमेशा खो गया था: शायद कुछ सबसे महत्वपूर्ण? तब मैंने सोचा - नहीं, इसके विपरीत, मैं सबसे महत्वपूर्ण को सबसे अधिक समझने योग्य संदर्भ में रखूंगा। यदि आप __in __ में कुछ डालते हैं। आरयू, और फिर यह सब आयात करते हैं, तो यह पता चलता है कि चक्रीय आयात भी खराब हैं।

मैंने विभिन्न लोकप्रिय पुस्तकालयों को देखा, उनकी __init __ पर चढ़ाई की। आरयू, और देखा कि मूल रूप से या तो कचरा या आवक संगतता है। मेरे लिए, यह सवाल तब तेजी से उठा, जब मैंने कई उप-पैकेजों के साथ बड़े पैकेज बनाने शुरू किए - आप खो जाते हैं। , . Python, , , __init__. , 90% .

— , API, , - , , ? , , . API . , __init__. - : , , .

, I_CONTROL_CODE — . , . , , __init__. — . , , , - , .

hasattr ?

hasattr ? , , Python — . hasattr , ().

, , hasattr , , . , hasattr, , . - , Python -, hasattr . , . getattr « , ». hasattr — getattr, exception .

50 50 — , , .

, layer-linter . ? : , , , . , - . - . .

cohesion . , . Cohesion , . False Positive , — , , .

vulture Python . - , Python , . ohesion.

Radon , : Halstead , Maintainability Index , . , — .

Final type

Final- Python. Typing Extensions, , . , - , — , . , - - , ? कोई जरूरत नहीं . - — , , , .

Gratis

, .



, .

, . , . , Python- , .

, Moscow Python Conf++ , . , , Python-.

. . , , , .