💃🏾 🍋 ⏮️ पायथन कार्यों को और भी बेहतर कैसे बनाया जाए 🗃️ 👘 🧑🏽‍🤝‍🧑🏻

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

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

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

विषय को ताज़ा करें

गणित फ़ंक्शंस से भरा हुआ है, हालांकि, उन्हें याद करना मुश्किल है। तो आइए अपने पसंदीदा अनुशासन पर वापस जाएं: विश्लेषण। आपने शायद f(x) = 2x + 3 जैसे फॉर्मूले देखे हैं। यह एक फ़ंक्शन है जिसे f कहा जाता f जो एक तर्क x लेता है और फिर दो बार x + 3 "रिटर्न" करता है। यद्यपि यह उन कार्यों के समान नहीं है जो हम पायथन में उपयोग किए जाते हैं, यह पूरी तरह से निम्नलिखित कोड के समान है:

 def f(x): return 2*x + 3

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

अच्छे कार्यों का राज

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

इसे स्पष्ट रूप से नाम दिया गया है
एकमात्र कर्तव्य के सिद्धांत के अनुरूप है
डॉक शामिल हैं
मान लौटाता है
50 से अधिक लाइनों से मिलकर बनता है
वह निर्मल है और यदि संभव हो तो शुद्ध है

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

नामांकन

यहाँ इस विषय पर मेरा पसंदीदा उद्धरण है, अक्सर गलती से डोनाल्ड के लिए जिम्मेदार ठहराया जाता है, लेकिन वास्तव में फिल कार्टन द्वारा स्वामित्व:

कंप्यूटर विज्ञान के लिए दो चुनौतियां हैं: कैश अमान्यकरण और नामकरण।

कोई फर्क नहीं पड़ता कि यह कितना मूर्खतापूर्ण लगता है, नामकरण वास्तव में एक मुश्किल बात है। यहाँ एक "खराब" फ़ंक्शन नाम का एक उदाहरण है:

 def get_knn_from_df(df):

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

इस फ़ंक्शन के नाम के साथ पहली समस्या यह है कि यह संक्षिप्ताक्षर का उपयोग करता है। संक्षिप्ताक्षरों के बजाय पूर्ण अंग्रेजी शब्दों का उपयोग करना बेहतर है और न ही ज्ञात संक्षिप्तीकरण । मेरे द्वारा शब्दों को छोटा करने का एकमात्र कारण बहुत अधिक पाठ टाइप करने में समय बर्बाद करना नहीं है, बल्कि किसी भी आधुनिक संपादक का स्वतः पूर्ण कार्य है , इसलिए आपको केवल एक बार फ़ंक्शन का पूरा नाम लिखना होगा। संक्षिप्त नाम एक समस्या है, क्योंकि यह अक्सर एक विषय क्षेत्र के लिए विशिष्ट है। उपरोक्त कोड में, knn अर्थ है "K-निकटतम पड़ोसी," और df अर्थ है "DataFrame," एक डेटा संरचना जो आमतौर पर पांडा लाइब्रेरी में उपयोग की जाती है। यदि कोई प्रोग्रामर जो इन संक्षिप्ताक्षरों को नहीं जानता है, तो कोड पढ़ता है, तो वह फ़ंक्शन नाम में लगभग कुछ भी नहीं समझेगा।

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

तो हम इस सुविधा का नाम कैसे बदलें? बस:

 def k_nearest_neighbors(dataframe):

अब यहां तक कि एक आम आदमी भी समझता है कि इस फ़ंक्शन में क्या गणना की जा रही है, और पैरामीटर नाम (dataframe) कोई संदेह नहीं छोड़ता है कि किस तर्क के साथ इसे पारित किया जाना चाहिए।

एकमात्र जिम्मेदारी

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

एक उदाहरण देना बेहतर है। यहाँ एक फ़ंक्शन है जो एक से अधिक "चीज़" करता है:

 def calculate_and print_stats(list_of_numbers): sum = sum(list_of_numbers) mean = statistics.mean(list_of_numbers) median = statistics.median(list_of_numbers) mode = statistics.mode(list_of_numbers) print('-----------------Stats-----------------') print('SUM: {}'.format(sum) print('MEAN: {}'.format(mean) print('MEDIAN: {}'.format(median) print('MODE: {}'.format(mode)

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

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

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

Dokstroki

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

प्रत्येक फ़ंक्शन को डॉक्टर स्ट्रिंग की आवश्यकता होती है।
यह व्याकरण और विराम चिह्न का निरीक्षण करना चाहिए; पूरा वाक्य लिखो
डॉकस्ट्रिंग एक संक्षिप्त (एक वाक्य में) से शुरू होता है कि फ़ंक्शन क्या करता है।
डॉकस्ट्रिंग को वर्णनात्मक शैली के बजाय एक प्रिस्क्रिप्टिव में तैयार किया गया है

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

मान लौटाएं

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

 ❯ python3 Python 3.7.0 (default, Jul 23 2018, 20:22:55) [Clang 9.1.0 (clang-902.0.39.2)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> def add(a, b): ... print(a + b) ... >>> b = add(1, 2) 3 >>> b >>> b is None True

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

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

 with open('foo.txt', 'r') as input_file: for line in input_file: if line.strip().lower().endswith('cat'): # ...     -

स्ट्रिंग if line.strip().lower().endswith('cat'): काम करती है क्योंकि प्रत्येक स्ट्रिंग मेथड ( strip() , lower() , endswith() ) फ़ंक्शन को कॉल करने के परिणामस्वरूप एक स्ट्रिंग देता है।

यहां कुछ सामान्य कारण दिए गए हैं जो एक प्रोग्रामर आपको यह समझा सकता है कि एक फ़ंक्शन वह क्यों लिखता है, एक मान वापस नहीं करता है:

“यह सिर्फ [इनपुट / आउटपुट से संबंधित किसी प्रकार का ऑपरेशन है, उदाहरण के लिए, डेटाबेस में एक मूल्य का भंडारण]। यहाँ मैं कुछ भी उपयोगी नहीं लौटा सकता। ”

मैं सहमत नहीं हूं। यदि ऑपरेशन सफलतापूर्वक पूरा हुआ, तो फ़ंक्शन सही वापस आ सकता है।

"यहां हम उपलब्ध मापदंडों में से एक को बदलते हैं, इसे संदर्भ पैरामीटर के रूप में उपयोग करते हैं।" "

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

“मुझे कई मूल्यों को वापस करने की आवश्यकता है। इस बात का कोई एक मूल्य नहीं है कि इस मामले में वापसी करना उचित होगा। ”

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

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

कार्य की लंबाई

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

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

तो क्या करें यदि आपका फ़ंक्शन बहुत लंबा है? Refactor! संभवतः आपको हर समय रिफैक्टिंग करना पड़ता है, भले ही आपको पद की जानकारी न हो। केवल व्यवहार को बदलने के बिना, रीफ़ैक्टरिंग किसी प्रोग्राम की संरचना को बदल रहा है। इसलिए, एक लंबे फ़ंक्शन से कोड की कई पंक्तियों को निकालना और उन्हें एक स्वतंत्र फ़ंक्शन में बदलना, रिफैक्टिंग के प्रकारों में से एक है। यह पता चला है कि यह लंबे समय तक काम करने के लिए सबसे आम और सबसे तेज़ तरीका है। चूंकि आप इन नए कार्यों को उपयुक्त नाम दे रहे हैं, परिणामी कोड को पढ़ना बहुत आसान है। मैंने रीफैक्टरिंग (वास्तव में, मैं इसे हर समय करता हूं) के बारे में एक पूरी किताब लिखी है, इसलिए मैं यहां विवरणों में नहीं गया हूं। बस पता है कि यदि आपके पास एक फ़ंक्शन है जो बहुत लंबा है, तो आपको इसे रिफैक्ट करना चाहिए।

आय और कार्यात्मक स्वच्छता

इस खंड का शीर्षक थोड़ा डराने वाला लग सकता है, लेकिन वैचारिक रूप से यह खंड सरल है। एक ही तरह के तर्कों के साथ एक आदर्श कार्य हमेशा एक ही मूल्य देता है, भले ही इसे कितनी बार कहा जाए। परिणाम गैर-स्थानीय चर, तर्कों की परिवर्तनशीलता या इनपुट / आउटपुट स्ट्रीम से आने वाले किसी भी डेटा पर निर्भर नहीं करता है। निम्नलिखित add_three(number) फ़ंक्शन idempotent है:

 def add_three(number): """ ** + 3.""" return number + 3

भले ही हम कितनी बार add_three(7) , इसका जवाब हमेशा 10 होगा। लेकिन एक और मामला एक ऐसा कार्य है जो add_three(7) नहीं है:

 def add_three(): """ 3 + ,  .""" number = int(input('Enter a number: ')) return number + 3

यह स्पष्ट रूप से विरोधाभासी फ़ंक्शन idempotent नहीं है, क्योंकि फ़ंक्शन का रिटर्न मान इनपुट / आउटपुट पर निर्भर करता है, अर्थात् उपयोगकर्ता द्वारा दर्ज की गई संख्या पर। बेशक, add_three() लिए अलग-अलग कॉल के साथ add_three() रिटर्न मान अलग-अलग होंगे। यदि हम दो बार इस फ़ंक्शन को कॉल करते हैं, तो पहले मामले में उपयोगकर्ता 3 में प्रवेश कर सकता है, और दूसरे में - 7, और फिर add_three() दो कॉल क्रमशः 6 और 10 वापस आएंगे।

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

क्यों बेवकूफी इतनी महत्वपूर्ण है

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

"शुद्ध" फ़ंक्शन क्या है?

कार्यात्मक प्रोग्रामिंग में, एक फ़ंक्शन को शुद्ध माना जाता है अगर, सबसे पहले , यह एक आदर्श है, और दूसरी बात , यह मनाया प्रभाव के प्रभाव का कारण नहीं है। मत भूलो: एक फ़ंक्शन एक आदर्श है यदि यह हमेशा उसी परिणाम को तर्कों के एक विशिष्ट सेट के साथ लौटाता है। हालांकि, इसका मतलब यह नहीं है कि फ़ंक्शन अन्य घटकों को प्रभावित नहीं कर सकता है - उदाहरण के लिए, गैर-स्थानीय चर या इनपुट / आउटपुट स्ट्रीम। उदाहरण के लिए, यदि उपर्युक्त add_three(number) फ़ंक्शन का add_three(number) संस्करण कंसोल में परिणाम का उत्पादन करता है, और उसके बाद ही इसे वापस लौटाता है, तब भी इसे idempotent माना जाएगा, क्योंकि जब यह इनपुट / आउटपुट स्ट्रीम का उपयोग करता है, तो यह एक्सेस ऑपरेशन लौटे मूल्य को प्रभावित नहीं करता है। समारोह से। print() कॉल केवल एक साइड इफेक्ट है : कार्यक्रम या सिस्टम के बाकी हिस्सों के साथ बातचीत, जैसे वापसी मूल्य के साथ घटित हो रही है।

चलिए हमारे उदाहरण को add_three(number) साथ थोड़ा विकसित करते हैं। आप कितनी बार add_three(number) कहा गया है यह निर्धारित करने के लिए आप निम्न कोड लिख सकते हैं:

 add_three_calls = 0 def add_three(number): """ ** + 3.""" global add_three_calls print(f'Returning {number + 3}') add_three_calls += 1 return number + 3 def num_calls(): """,     *add_three*.""" return add_three_calls

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

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

शुद्ध कार्यों में लॉगिंग निर्देश या print() कॉल नहीं होते हैं। काम करते समय, वे डेटाबेस का उपयोग नहीं करते हैं और इंटरनेट कनेक्शन का उपयोग नहीं करते हैं। गैर-स्थानीय चर तक पहुँच या संशोधन न करें। और अन्य गैर-शुद्ध कार्यों को न कहें ।

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

ईमानदारी से, आलस्य और सफाई बहुत वांछनीय है, लेकिन आवश्यक नहीं है। , , , . , , , , . , , .

निष्कर्ष

वह सब है। , – . . , . – ! . , , , « ». .

पायथन कार्यों को और भी बेहतर कैसे बनाया जाए