🧙🏽 👋🏿 📏 अजगर गाइड। एक महान कोड लेखन ✋ 👵 🙁

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

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

केनेथ फोटोग्राफी

केनेथ रिट्ज एट पायकोन ऑस्ट्रेलिया (2012)

इसके बाद ही लेख है। (यदि आपको त्रुटियां मिलती हैं, हमेशा की तरह - तुरंत उनके बारे में चिल्लाएं! त्रुटियों को ठीक करने की आवश्यकता है।)

अपनी परियोजना की संरचना करें

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

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

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

संरचना तय करती है

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

बस संरचित परियोजना - इसका मतलब है कि यह केवल एक खराब संरचित परियोजना बनाना भी संभव है। खराब संरचित परियोजना के कुछ संकेत:

एकाधिक और गंदे चक्रीय निर्भरता। यदि Carpenter प्रश्न का उत्तर देने के लिए Carpenter वर्ग को Table क्लास और Chair क्लास को आयात करने की आवश्यकता है, तो प्रश्न table.isdoneby() का उत्तर देने के लिए आपकी Table और Chair क्लास को workers.py मॉड्यूल से Carpenter वर्ग को आयात करने की आवश्यकता है। carpenter.whatdo() - आपको एक परिपत्र निर्भरता मिलती है। इस मामले में, आपको ट्रिकी ट्रिक्स का सहारा लेना होगा, जैसे कि विधियों या कार्यों के अंदर आयात विवरण का उपयोग करना।
छिपे हुए कनेक्शन। Table वर्ग में प्रत्येक परिवर्तन असंबंधित परीक्षणों में 20 परीक्षणों में विफल रहता है, क्योंकि यह Carpenter वर्ग कोड के निष्पादन को विकृत करता है, जिसके लिए सर्जिकल रूप से सूक्ष्म अनुकूली कोड परिवर्तन की आवश्यकता होती है। इसका मतलब यह है कि आपके पास Carpenter वर्ग या इसके विपरीत के कोड में तालिका वर्ग के बारे में बहुत सारे "सम्मेलन" हैं।
वैश्विक नामस्थान या संदर्भ का गहन उपयोग। Table और Carpenter वर्गों के साथ स्पष्ट रूप से गुजरने (ऊंचाई, चौड़ाई, प्रकार, पेड़) चर के बजाय, आप वैश्विक चर पर भरोसा करते हैं जिन्हें अलग-अलग "कॉमरेड" द्वारा मक्खी पर बदला और संशोधित किया जा सकता है। आपको उन सभी स्थानों की सावधानीपूर्वक जांच करनी चाहिए जहां आप इन वैश्विक चर का उपयोग कर सकते हैं यह समझने के लिए कि आयताकार तालिका क्यों वर्गाकार हो गई है और यह पता लगाने के लिए कि दूरस्थ कोड भी तालिका के आकार को बदलकर इस संदर्भ में बदलाव आया है।
स्पेगेटी कोड। नेस्टेड के कई पृष्ठ if निर्माण और लूप कोड के बहुत सारे के साथ और कोई सेगमेंटिंग नहीं करता है, जिसे स्पेगेटी कोड के रूप में जाना जाता है। पायथन में महत्वपूर्ण इंडेंटेशन के लिए धन्यवाद (सबसे अधिक चर्चा की गई विशेषताओं में से एक), इस भाषा में इस तरह के कोड को लिखना बहुत मुश्किल है। इसलिए अच्छी खबर है - आप अक्सर इस तरह के कोड का पालन नहीं करेंगे।
रवियोली कोड। ऐसा कोड पायथन के लिए अधिक विशिष्ट है। इसमें उचित संरचना के बिना तर्क, वर्ग या वस्तुओं के सैकड़ों समान (या एक दूसरे के समान) टुकड़े होते हैं। यदि आपको याद नहीं है कि आपकी समस्या को हल करने के लिए FurnitureTable , AssetTable या Table या यहां तक कि Table AssetTable का उपयोग न करें, तो आप रैवियोली कोड में स्नान करेंगे।

मॉड्यूल

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

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

जैसे ही आप आयात विवरण का उपयोग शुरू करते हैं, आप मॉड्यूल का उपयोग करना शुरू कर देते हैं। ये निर्मित मॉड्यूल, जैसे os और sys , तृतीय-पक्ष मॉड्यूल हो सकते हैं जिन्हें आपने अपने वातावरण में स्थापित किया है, या आपकी परियोजना के आंतरिक मॉड्यूल।

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

इस उदाहरण में, पायथन को " my " नाम के फ़ोल्डर में " spam.py " खोजने की उम्मीद है जो मौजूद नहीं है। पायथन डॉक्स में डॉट नोटेशन का उपयोग कैसे किया जाना चाहिए, इसका एक उदाहरण है।

यदि आप चाहें, तो आप फ़ाइल को my_spam.py नाम दे सकते हैं, लेकिन यहां तक कि हमारे मित्र - रेखांकित - को भी अक्सर मॉड्यूल नामों में उपयोग नहीं किया जाना चाहिए।

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

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

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

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

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

यह आपको अभिव्यक्ति आयात के विशेष सिंटैक्स का उपयोग करके अधिक मानक व्यवहार करने की अनुमति देता है: from module import * । यह आमतौर पर बुरा अभ्यास माना जाता है। " import * " का उपयोग कोड को पढ़ने में कठिन बनाता है और निर्भरता को कम खंडित करता है।

from module import func का उपयोग उस फ़ंक्शन को इंगित करने का एक तरीका है जिसे आप आयात करना चाहते हैं और वैश्विक दायरे में डालते हैं। और यह भी " import * " की तुलना में कोड के लिए कम हानिकारक है, क्योंकि यहां यह स्पष्ट रूप से देखा गया है कि वैश्विक दायरे में क्या आयात किया जाता है, किस्ट्रोक्स को बचाने के लिए एक सरल आयात मॉड्यूल प्रविष्टि का लाभ है।

 # Very bad [...] from modu import * [...] x = sqrt(4) # Is sqrt part of modu? A builtin? Defined above? # Better from modu import sqrt [...] x = sqrt(4) # sqrt may be part of modu, if not redefined in between # Best import modu [...] x = modu.sqrt(4) # sqrt is visibly part of modu's namespace

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

अजगर गाइड। एक महान कोड लेखन

केनेथ रिट्ज एट पायकोन ऑस्ट्रेलिया (2012)

अपनी परियोजना की संरचना करें

संरचना तय करती है

मॉड्यूल

More articles: