मांग पर जटिलता झरना और वास्तुकला

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

लेकिन, यह अंततः एक कारण के लिए होता है! कोड जटिलता दो संभावित तरीकों से आपके कोडबेस में प्रवेश करती है: बड़ी मात्रा में और वृद्धिशील परिवर्धन के साथ। और लोग दोनों की समीक्षा करने और खोजने में बुरे हैं।

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

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

तो, आपके कोड को जटिल होने से रोकने के लिए क्या किया जा सकता है? हमें स्वचालन का उपयोग करने की आवश्यकता है! आइए कोड जटिलता और खोजने और अंततः इसे हल करने के तरीकों में एक गहरा गोता लगाएँ।

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

जटिलता समझाया

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

याद रखें, कि इस लेख का नाम "जटिलता झरना" है? मैं आपको दिखाऊंगा कि सबसे सरल आदिम से जटिलता सबसे अधिक अमूर्तता में कैसे बहती है।

मैं अपने उदाहरणों के लिए मुख्य भाषा के रूप में python का उपयोग करूंगा और अपने कोड में उल्लंघनों को खोजने और अपनी बात को स्पष्ट करने के लिए मुख्य लाइनिंग टूल के रूप में wemake-python-styleguide ।

भाव

आपके सभी कोड में a + 1 और print(x) जैसे सरल भाव होते हैं। हालांकि अभिव्यक्तियाँ स्वयं सरल हैं, वे किसी बिंदु पर जटिलता के साथ आपके कोड को अनजाने में ओवरफ़्लो कर सकते हैं। उदाहरण: कल्पना करें कि आपके पास एक शब्दकोश है जो किसी User मॉडल का प्रतिनिधित्व करता है और आप इसका उपयोग इस तरह करते हैं:

 def format_username(user) -> str: if not user['username']: return user['email'] elif len(user['username']) > 12: return user['username'][:12] + '...' return '@' + user['username'] 

यह बहुत आसान लग रहा है, है ना? वास्तव में, इसमें दो अभिव्यक्ति-आधारित जटिलता मुद्दे शामिल हैं। यह overuses 'username' स्ट्रिंग का उपयोग करता है और मैजिक नंबर 12 का उपयोग करता है (हम पहली बार इस नंबर का उपयोग क्यों करते हैं, 13 या 10 क्यों नहीं?)। इस प्रकार की चीजों को अपने आप से ढूंढना कठिन है। यहां बताया गया है कि बेहतर संस्करण कैसा दिखेगा:

 #: That's how many chars fit in the preview box. LENGTH_LIMIT: Final = 12 def format_username(user) -> str: username = user['username'] if not username: return user['email'] elif len(username) > LENGTH_LIMIT: # See? It is now documented return username[:LENGTH_LIMIT] + '...' return '@' + username 

अभिव्यक्ति के साथ-साथ विभिन्न समस्याएं भी हैं। हमारे पास some_object.some_attr अभिव्यक्तियाँ भी हो सकती हैं: जब आप एक नया स्थानीय चर बनाने के बजाय some_object.some_attr विशेषता का हर जगह उपयोग करते हैं। हमारे पास बहुत जटिल तर्क स्थितियां या बहुत गहरी डॉट एक्सेस भी हो सकती हैं ।

समाधान : नए चर, तर्क या स्थिरांक बनाएं। अगर आपको करना है तो नए यूटिलिटी फंक्शन या तरीके बनाएं और इस्तेमाल करें।

पंक्तियां

अभिव्यक्तियाँ कोड लाइनें बनाती हैं (कृपया, बयानों के साथ लाइनों को भ्रमित न करें: एक बयान में कई लाइनें हो सकती हैं और कई कथन एक ही पंक्ति में स्थित हो सकते हैं)।

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

विचार सरल है। आप केवल 80 वर्णों की तुलना में 160 चरों के साथ एक पंक्ति में दोगुने तर्क दे सकते हैं। इसलिए इस सीमा को निर्धारित और लागू किया जाना चाहिए। याद रखें, यह एक शैलीगत पसंद नहीं है । यह एक जटिलता मीट्रिक है!

दूसरी मुख्य लाइन जटिलता मीट्रिक कम ज्ञात है और कम उपयोग की जाती है। इसे जोन्स कॉम्प्लेक्सिटी कहा जाता है। इसके पीछे का विचार सरल है: हम इसकी जटिलता प्राप्त करने के लिए एक ही पंक्ति में कोड (या ast ) नोड्स की गणना करते हैं। आइए एक उदाहरण देखें। ये दो पंक्तियाँ जटिलता की दृष्टि से मौलिक रूप से भिन्न हैं, लेकिन वर्णों में इसकी समान चौड़ाई है:

 print(first_long_name_with_meaning, second_very_long_name_with_meaning, third) print(first * 5 + math.pi * 2, matrix.trans(*matrix), display.show(matrix, 2)) 

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

एक उच्च जोन्स जटिलता स्कोर के साथ लाइनों के साथ क्या करना है?

समाधान : उन्हें कई लाइनों में विभाजित करें या नए मध्यवर्ती चर, उपयोगिता कार्य, नई कक्षाएं आदि बनाएं।

 print( first * 5 + math.pi * 2, matrix.trans(*matrix), display.show(matrix, 2), ) 

अब यह अधिक पठनीय है!

संरचनाएं

अगला चरण भाषा संरचनाओं का विश्लेषण कर रहा है जैसे if , जैसे, with , आदि जो रेखाओं और अभिव्यक्तियों से बनते हैं। मेरा कहना है कि यह बिंदु बहुत भाषा-विशिष्ट है। मैं इस श्रेणी से python साथ-साथ कई नियमों का प्रदर्शन करूँगा।

हम if साथ शुरू करेंगे। एक अच्छे-बूढ़े से आसान क्या हो सकता है if ? वास्तव में, if वास्तव में तेजी से मुश्किल होने लगता है। यहाँ एक उदाहरण दिया गया है कि कैसे कोई reimplement switch को reimplement switch से लागू कर सकता है:

 if isinstance(some, int): ... elif isinstance(some, float): ... elif isinstance(some, complex): ... elif isinstance(some, str): ... elif isinstance(some, bytes): ... elif isinstance(some, list): ... 

इस कोड में क्या समस्या है? ठीक है, कल्पना कीजिए कि हमारे पास दसियों प्रकार के डेटा हैं, जिन्हें सीमा शुल्क सहित कवर किया जाना चाहिए, जिनके बारे में हमें अभी तक जानकारी नहीं है। फिर यह जटिल कोड एक संकेतक है कि हम यहां एक गलत पैटर्न चुन रहे हैं। हमें इस समस्या को ठीक करने के लिए अपना कोड रिफलेक्टर करना होगा। उदाहरण के लिए, कोई typeclass es या singledispatch उपयोग कर सकता है। वे एक ही नौकरी करते हैं, लेकिन अच्छे हैं।

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

 with first(), second(), third(), fourth(): ... 

आप किसी भी संख्या के साथ और अभिव्यक्ति के for समझ लिख सकते हैं, जिससे जटिल, अपठनीय कोड हो सकता है:

 [ (x, y, z) for x in x_coords for y in y_coords for z in z_coords if x > 0 if y > 0 if z > 0 if x + y <= z if x + z <= y if y + z <= x ] 

इसकी तुलना सरल और पठनीय संस्करण से करें:

 [ (x, y, z) for x, y, x in itertools.product(x_coords, y_coords, z_coords) if valid_coordinates(x, y, z) ] 

आप गलती से multiple statements inside a try मामले में multiple statements inside a try भी शामिल कर सकते हैं, जो असुरक्षित है क्योंकि यह अपेक्षित स्थान पर अपवाद को बढ़ा सकता है और संभाल सकता है:

 try: user = fetch_user() # Can also fail, but don't expect that log.save_user_operation(user.email) # Can fail, and we know it except MyCustomException as exc: ... 

और यह 10% मामलों में भी नहीं है जो आपके python कोड के साथ गलत हो सकता है और चलेगा। कई, कई और अधिक किनारे मामले हैं जिन्हें ट्रैक और विश्लेषण किया जाना चाहिए।

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

कार्य

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

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

मेरे अनुभव के आधार पर कई उपयोगी जटिलता मेट्रिक्स को नियमित फ़ंक्शन की लंबाई के बजाय गिना जाना चाहिए:

• फ़ंक्शन डेकोरेटर की संख्या; कम बेहतर है
• तर्कों की संख्या; कम बेहतर है
• एनोटेशन की संख्या; बेहतर है
• स्थानीय चर की संख्या; कम बेहतर है
• रिटर्न, पैदावार, इंतजार की संख्या; कम बेहतर है
• बयानों और अभिव्यक्तियों की संख्या; कम बेहतर है

इन सभी चेकों का संयोजन वास्तव में आपको सरल फ़ंक्शन लिखने की अनुमति देता है (सभी नियमों को भी तरीकों पर लागू किया जाता है)।

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

समाधान : जब एक फ़ंक्शन बहुत जटिल है, तो आपके पास एकमात्र समाधान इस फ़ंक्शन को कई लोगों में विभाजित करना है।

कक्षाएं

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

कक्षाओं के लिए हमें निम्नलिखित मैट्रिक्स को मापना होगा:

• कक्षा-स्तरीय सज्जाकारों की संख्या; कम बेहतर है
• बेस कक्षाओं की संख्या; कम बेहतर है
• वर्ग-स्तरीय सार्वजनिक विशेषताओं की संख्या; कम बेहतर है
• उदाहरण-स्तर की सार्वजनिक विशेषताओं की संख्या; कम बेहतर है
• तरीकों की संख्या; कम बेहतर है

जब इनमें से कोई भी अत्यधिक जटिल है - हमें अलार्म बजना होगा और निर्माण को विफल करना होगा!

समाधान : अपने असफल वर्ग को रिफलेक्टर करें! एक मौजूदा जटिल वर्ग को कई सरल लोगों में विभाजित करें या नए उपयोगिता कार्य बनाएं और रचना का उपयोग करें।

उल्लेखनीय उल्लेख: कोई आपके OOP डिज़ाइन की जटिलता को मान्य करने के लिए सामंजस्य और युग्मन मीट्रिक भी ट्रैक कर सकता है।

मॉड्यूल

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

हमें जाँचने के लिए मॉड्यूल की जटिलता का विश्लेषण करना है:

• आयात और आयातित नामों की संख्या; कम बेहतर है
• कक्षाओं और कार्यों की संख्या; कम बेहतर है
• अंदर कार्यों और कक्षाओं की औसत जटिलता; कम बेहतर है

एक जटिल मॉड्यूल के मामले में हम क्या करते हैं?

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

संकुल

पैकेज में कई मॉड्यूल होते हैं। सौभाग्य से, यह सब वे करते हैं।

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

समाधान : आपको पैकेज को उप-पैकेज और विभिन्न स्तरों के पैकेज में विभाजित करना होगा।

जटिलता झरना प्रभाव

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

यह हमें इस लेख के सबसे महत्वपूर्ण विचार की ओर ले जाता है: अपने कोड को जटिलता के साथ बहने न दें। मैं कई उदाहरण दूंगा कि यह आमतौर पर कैसे होता है।

कल्पना कीजिए कि आप एक नई सुविधा लागू कर रहे हैं। और यह एकमात्र परिवर्तन है जो आप करते हैं:

 +++ if user.is_active and user.has_sub() and sub.is_due(tz.now() + delta): --- if user.is_active and user.has_sub(): 

ठीक लगता है, मैं इस कोड को समीक्षा पर पास कर दूंगा। और कुछ भी बुरा नहीं होगा। लेकिन, मुझे जो बात याद आ रही है, वह यह है कि जटिलता इस रेखा से बह निकली है! यही wemake-python-styleguide रिपोर्ट करेगा:

ठीक है, हमें अब इस जटिलता को हल करना होगा। चलो एक नया चर बनाते हैं:

 class Product(object): ... def can_be_purchased(self, user_id) -> bool: ... is_sub_paid = sub.is_due(tz.now() + delta) if user.is_active and user.has_sub() and is_sub_paid: ... ... ... 

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

 class Product(object): ... def can_be_purchased(self, user_id) -> bool: ... if self._has_paid_sub(user, sub, delta): ... ... def _has_paid_sub(self, user, sub, delta) -> bool: is_sub_paid = sub.is_due(tz.now() + delta) return user.is_active and user.has_sub() and is_sub_paid ... 

अब हम कर चुके हैं! है न? नहीं, क्योंकि हमें अब Product वर्ग की जटिलता की जांच करनी है। कल्पना कीजिए, कि अब हमारे पास एक नया _has_paid_sub कई तरीके हैं।

ठीक है, हम फिर से जटिलता की जांच करने के लिए अपना लिंटर चलाते हैं। और हमारे Product वर्ग वास्तव में अभी बहुत जटिल है। हमारे कर्म? हमने इसे कई वर्गों में विभाजित किया है!

 class Policy(object): ... class SubcsriptionPolicy(Policy): ... def can_be_purchased(self, user_id) -> bool: ... if self._has_paid_sub(user, sub, delta): ... ... def _has_paid_sub(self, user, sub, delta) -> bool: is_sub_paid = sub.is_due(tz.now() + delta) return user.is_active and user.has_sub() and is_sub_paid class Product(object): _purchasing_policy: Policy ... ... 

कृपया मुझे बताएं कि यह अंतिम चलना है! खैर, मुझे खेद है, लेकिन हमें अब मॉड्यूल जटिलता की जांच करनी होगी। और लगता है क्या? अब हमारे पास बहुत से मॉड्यूल सदस्य हैं। इसलिए, हमें मॉड्यूल को अलग-अलग में विभाजित करना होगा! फिर हम पैकेज की जटिलता की जांच करते हैं। और संभवतः इसे कई उप-पैकेजों में विभाजित भी करता है।

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

इसे ही मैं "सतत रिफ़ैक्टरी" प्रक्रिया कहता हूं। आपको रिफ्लेक्टरिंग करने के लिए मजबूर किया जाता है। हमेशा।

इस प्रक्रिया का एक दिलचस्प परिणाम भी है। यह आपको "आर्किटेक्चर ऑन डिमांड" की अनुमति देता है। मुझे समझाने की। "आर्किटेक्चर ऑन डिमांड" दर्शन के साथ आप हमेशा छोटी शुरुआत करते हैं। उदाहरण के लिए एकल logic/domains/user.py फ़ाइल। और आप अपना सब कुछ वहां से संबंधित User को डालना शुरू करते हैं क्योंकि इस समय आप शायद नहीं जानते कि आपकी वास्तुकला कैसी दिखेगी। और आप परवाह नहीं करते। आपको केवल तीन फ़ंक्शन पसंद हैं।

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

"आर्किटेक्चर ऑन डिमांड" अवधारणा इन समस्याओं को हल करती है। आप छोटी शुरुआत करते हैं, जब समय आता है - आप चीजों को विभाजित करते हैं और रिफ्लेक्टर करते हैं:

1. आप logic/domains/user.py साथ शुरू करते हैं और वहाँ सब कुछ डालते हैं
2. बाद में जब आपके पास पर्याप्त डेटाबेस से संबंधित सामान हो, तो आप logic/domains/user/repository.py बनाते हैं
3. जब आप ऐसा करने के लिए कहते हैं, तब आप इसे logic/domains/user/repository/queries.py और logic/domains/user/repository/commands.py logic/domains/user/repository/queries.py में विभाजित करते हैं।
4. फिर आप http से संबंधित सामान के साथ logic/domains/user/services.py बनाएँ
5. फिर आप एक नया मॉड्यूल बनाते हैं, जिसे logic/domains/order.py
6. वगैरह वगैरह

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

निष्कर्ष

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

उदाहरण के लिए, wemake-python-styleguide python स्रोत कोड जटिलता के साथ आपकी मदद कर सकता है, यह इसके लिए अनुमति देता है:

• सभी स्तरों पर सफलतापूर्वक जटिलता से लड़ें
• नामकरण मानकों, सर्वोत्तम प्रथाओं और स्थिरता जांच की विशाल मात्रा को लागू करें
• आसानी से flakehell विकल्‍प या flakehell टूल की मदद से इसे एक विरासत कोड आधार में एकीकृत किया जाता है, इसलिए पुराने उल्‍लंघन को माफ कर दिया जाएगा, लेकिन नए लोगों को अनुमति नहीं दी जाएगी।
• इसे अपने [CI] () में सक्षम करें, यहां तक ​​कि एक Github एक्शन के रूप में भी

अपने कोड को ओवरफ़्लो करने की जटिलता को न दें, एक अच्छे लिंटर का उपयोग करें !