ऑनलाइन प्रसारित होने वाली अनगिनत पायथन सर्वोत्तम प्रथाओं के साथ, प्रत्येक पर राय आपके द्वारा पूछे जाने वाले आधार पर भिन्न हो सकती है। इंटरनेट ने विशेषज्ञता को लोकतांत्रिक बना दिया है, जिससे किसी को भी - जिसमें मैं भी शामिल हूं - अपने विचार साझा करने की इजाजत मिलती है। हालाँकि, इस लेख में, हम 10 शाश्वत पायथन सर्वोत्तम प्रथाओं पर ध्यान केंद्रित करेंगे जिन्होंने व्यापक सहमति हासिल की है और व्यापक रूप से मौलिक माने जाते हैं।

पांडास चीटशीट

गिट कमांड्स चीटशीट

शीर्ष 50 एसक्यूएल साक्षात्कार प्रश्न

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

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

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

टिप 4: बंद सिद्धांतों को खोलें
खुला-बंद सिद्धांत (ओसीपी) कहता है कि एक वर्ग, विधि या फ़ंक्शन विस्तार के लिए खुला होना चाहिए लेकिन संशोधन के लिए नहीं। इसका मतलब यह है कि परिभाषित किसी भी वर्ग, विधि या फ़ंक्शन को उसके कोड को बदले बिना कई उदाहरणों के लिए आसानी से पुन: उपयोग या विस्तारित किया जा सकता है।
यह OCP का पालन करने में विफल रहता है क्योंकि जब भी कोई नया देश होता है, तो हमें उसके पूरक के लिए एक नया if कथन लिखना होगा। यह अब सरल लग सकता है लेकिन कल्पना करें कि हमारे पास ध्यान में रखने के लिए 100 या अधिक देश हैं। वह कैसा दिखेगा?

टिप 5: हर कीमत पर टिप्पणियों से बचें
टिप्पणियाँ मिथ्या सत्य होने का एक तरीका है। वे पाठक के दिमाग को इस बात से भटका देते हैं कि कोड वास्तव में क्या कर रहा है और कोई दूसरा क्या कह रहा है।

जैसे-जैसे समय बीतता है और कोड अपडेट या परिवर्तन प्राप्त करता है, यह बहुत समस्याग्रस्त हो सकता है। कुछ बिंदु पर, टिप्पणी झूठ बन जाती है और हर किसी को अब झूठ के चश्मे से सच्चाई का निरीक्षण करना पड़ता है।

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

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

टिप 6: जादुई नंबरों से बचें
मैजिक नंबर एक हार्ड-कोडित मान है जो बाद के चरण में बदल सकता है, लेकिन इसलिए इसे अपडेट करना कठिन हो सकता है।

उदाहरण के लिए, मान लें कि आपके पास एक पेज है जो "आपके ऑर्डर" अवलोकन पृष्ठ में पिछले 50 ऑर्डर प्रदर्शित करता है। 50 यहां जादुई संख्या है क्योंकि यह मानक या परंपरा के माध्यम से निर्धारित नहीं है, यह एक संख्या है जिसे आपने विनिर्देश में उल्लिखित कारणों से बनाया है।

अब, आप क्या करते हैं कि आपके पास अलग-अलग स्थानों पर 50 हैं - आपकी एसक्यूएल स्क्रिप्ट (ऑर्डर से शीर्ष 50 * चुनें), आपकी वेबसाइट (आपके पिछले 50 ऑर्डर), आपका ऑर्डर लॉगिन ((i = 0; i

टिप 7: गहरे घोंसले बनाने से बचें
पठनीयता में सुधार के लिए लूप, कंडीशनल या फ़ंक्शंस के भीतर नेस्टिंग के स्तर को सीमित करें।

टिप 8: हार्डकोडिंग पथों से बचें
हार्डकोडिंग फ़ाइल पथ या यूआरएल से बचना; इसके बजाय कॉन्फ़िगरेशन फ़ाइलों या पर्यावरण चर का उपयोग करें।

टिप 9: कक्षाएं छोटी होनी चाहिए
हाँ! कक्षाएँ यथासंभव छोटी होनी चाहिए। बिल्कुल कार्यों की तरह।

केवल अंतर यह है कि फ़ंक्शन में, आकार उस फ़ंक्शन में लाइनों की संख्या से निर्धारित होता है जबकि कक्षाओं में, यह उस वर्ग में जिम्मेदारियों की संख्या से निर्धारित होता है।

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

यह हमें एसआरपी (एकल जिम्मेदारी सिद्धांत) पर वापस ले जाता है जो बताता है कि एक वर्ग के पास बदलाव के लिए केवल एक ही कारण - एक जिम्मेदारी - होनी चाहिए।

टिप 10: जटिल त्रिक अभिव्यक्तियों से बचें
अत्यधिक जटिल त्रिक अभिव्यक्तियों का उपयोग करने से बचें; कोड को अधिक समझने योग्य बनाने के लिए संक्षिप्तता के बजाय पठनीयता को प्राथमिकता दें।