कुछ पीएचपी

Question

में एक समारोह से एक दिए गए मान अनदेखी उदाहरण के लिए के साथ गलत:

// somefile.php 
function doSomething() { 
    // do lots of code, whatever... 
    return $something; 
} 

// mainfile.php 
include "somefile.php" 
doSomething(); // ignored the return value, we don't need it here 

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

Answer 1

वापसी मूल्य त्याग दिया गया है। ऐसा करने में कुछ भी गलत नहीं है। यहां तक ​​कि एक स्पष्ट return बिना कार्यों null वापसी करते परोक्ष:

function foo() {} 
var_dump(foo()); // NULL 

Answer 2

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

इसके अलावा, ऐसे कार्य आमतौर पर Command Query separation से ग्रस्त हैं।

कुछ उदाहरण:

• array_unshift(&$arr, $value, ...) पहले जोड़ता है पारित कर दिया सरणी के लिए मूल्यों और सरणी के नए आकार देता है, आप उस जानकारी को कितनी बार करना चाहते हैं? और यदि आप करते हैं, तो आप हमेशा इस उद्देश्य के लिए डिज़ाइन किए गए count($array) पर कॉल कर सकते हैं।

• sort(&$arr) प्रकार सरणी पारित हो गई और अगर यह सफल हो तो लौटाता है। क्या इस का कोई मतलब निकलता है? जब कुछ गलत हुआ तो आपको पता होना चाहिए, अपवाद उठाया जाना चाहिए/त्रुटि ट्रिगर की गई है, क्या आप वास्तव में हर समय सफलता का परीक्षण करना चाहते हैं? और क्या तुम?

• print_r() इसका उबर-उदाहरण है, यह आपके द्वारा पारित तर्कों के आधार पर सत्य (हमेशा ऐसा बेकार है) या स्ट्रिंग देता है। यह निश्चित रूप से नहीं है कि एपीआई कैसा दिखना चाहिए।

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

एचआईएनटी: कुछ परीक्षण लिखें और अपने आर्किटेक्चर पर पुनर्विचार करें, अगर यह वास्तव में किसी अन्य तरीके से समझ में नहीं आता है, तो शायद यह काफी अच्छा है। लेकिन आपको हमेशा ऐसी परिस्थितियों में सावधान रहना चाहिए।

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

मेरे लिए यह सब एक सरल प्रतिमान के नीचे गेंदबाजी:

"एक समारोह एक बात करना चाहिए। इसे अच्छी तरह से करना चाहिए। इसे केवल यह करना चाहिए। "

यदि आपके पास उस समारोह को कॉल करने के एक से अधिक कारण हैं तो बहुत कुछ करना है।

---

एक भाषा दृष्टिकोण से वहाँ बिल्कुल वापसी मूल्यों की अनदेखी के साथ कोई समस्या नहीं है। से क्लीन कोड स्टैंडपॉइंट है।

ए insert() फ़ंक्शन को डेटाबेस में एक रिकॉर्ड डालना चाहिए। सम्मिलित रिकॉर्ड की आईडी वापस नहीं। आपने इसके लिए नहीं पूछा था।

ए setLatitude() वस्तुओं को आंतरिक स्थिति को संशोधित करना चाहिए जो आपके टाइमज़ोन वर्ग को लोड नहीं करते हैं और यह आंकड़ा है कि अक्षांश उस समय क्षेत्र में है और वे डेटाबेस को लिखते हैं। (वस्तु को सहेजना ऐसा कर सकता है)।

---

आप दो कारणों से एक समारोह में यह एक से अधिक उद्देश्य में कार्य करता है और यह दृश्य इसलिए की एक साफ कोड बिंदु से कॉल करने के लिए है, तो: "बहुत ज्यादा करता है"

निश्चित रूप से ऐसे मामले भी निर्माण किया जा सकता है जहां यह समझ में आता है लेकिन अंगूठे के सामान्य नियम के रूप में वापसी मूल्य एक कोड गंध हो सकता है।