क्या मूल्य द्वारा पारित मापदंडों के मूल्यों को संशोधित नहीं करने का एक कारण है?

Question

क्या किसी फ़ंक्शन के उद्देश्य में बाय-वैल्यू मापदंडों के मूल्यों को संशोधित करने के लिए उद्देश्यपूर्ण, सहायक सॉफ्टवेयर-इंजीनियरिंग तर्क हैं?

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

क्या यह एक गैर-resolvable धार्मिक संघर्ष है, या दोनों दिशाओं में अच्छे, उद्देश्य सॉफ़्टवेयर इंजीनियरिंग कारण हैं?

नोट: सिद्धांत का प्रश्न विशेष भाषा के कार्यान्वयन के विवरण की परवाह किए बिना रहता है। जावास्क्रिप्ट में, उदाहरण के लिए, जहां तर्कों की सूची हमेशा गतिशील होती है, पैरामीटर को argumentsऑब्जेक्ट से स्थानीय चर आरंभ के लिए सिंटैक्टिक चीनी माना जा सकता है । फिर भी, कोई भी पैरामीटर घोषित पहचानकर्ताओं को "विशेष" के रूप में मान सकता है क्योंकि वे अभी भी कॉल करने वाले से कैली तक जानकारी पारित कर रहे हैं।

Comments

यह अभी भी भाषा-विशिष्ट है; यह तर्क देना कि यह भाषा-अज्ञेयवादी है क्योंकि "ऐसा है, मेरी (पसंदीदा भाषा) की दृष्टि से" अमान्य तर्क का एक रूप है। दूसरा कारण यह है कि यह भाषा-विशिष्ट है क्योंकि एक सवाल जिसका सभी भाषाओं के लिए सार्वभौमिक उत्तर नहीं है, प्रत्येक भाषा की संस्कृतियों और मानदंडों के अधीन है; इस मामले में, विभिन्न भाषा-विशिष्ट मानदंड इस प्रश्न के अलग-अलग उत्तर देते हैं।

— रवांग

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

— रॉबर्ट हार्वे

मैंने सोचा था कि यह पहले पूछा गया होगा, लेकिन मुझे लगता है कि केवल एक ही ढोंगी है तो यह पुराने एसओ सवाल हो सकता है ।

— डॉक्टर ब्राउन

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

— फ्रैंक हिलमैन

Answer 1

मैं असहमत हूं और कहता हूं कि पैरामीटर विधि को कॉल करने के सिंटैक्स द्वारा आरंभ किए गए स्थानीय चर से ज्यादा कुछ नहीं हैं

मैं एक तीसरी स्थिति अपनाता हूं: पैरामीटर स्थानीय चर की तरह हैं: दोनों को डिफ़ॉल्ट रूप से अपरिवर्तनीय माना जाना चाहिए। अतः चर एक बार नियत किए जाते हैं और फिर केवल परिवर्तित किए जाते हैं। लूप के मामले में, for each (x in ...)चर प्रत्येक पुनरावृत्ति के संदर्भ में अपरिवर्तनीय है। इसके कारण हैं:

1. यह कोड को "मेरे सिर में निष्पादित करना" आसान बनाता है:
2. यह चर के लिए अधिक वर्णनात्मक नाम की अनुमति देता है।

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

उसी विधि का सामना करते हुए, इस बार कम चर के साथ, लेकिन वह परिवर्तन हर समय मूल्य रखता है, मुझे अब उन चर की वर्तमान स्थिति को याद रखना होगा, साथ ही साथ कोड क्या कर रहा है, इस पर काम करना होगा।

मेरे अनुभव में, पूर्व मेरे गरीब मस्तिष्क पर बहुत आसान है। अन्य, चतुर, मेरे से अधिक लोगों को यह समस्या नहीं हो सकती है, लेकिन यह मेरी मदद करता है।

अन्य बिंदु के लिए के रूप में:

double Foo(double r)
{
    r = r * r;
    r = Math.Pi * r;
    return r;
}

बनाम

double Foo(int r)
{
    var rSquared = r * r;
    var area = Math.Pi * rSquared;
    return area;
} 

उदाहरणों से वंचित, लेकिन मेरे दिमाग में यह बहुत स्पष्ट है कि चर नामों के कारण दूसरे उदाहरण में क्या हो रहा है: वे rपहले उदाहरण में उस द्रव्यमान की तुलना में पाठक को अधिक जानकारी देते हैं ।

Comments

"स्थानीय चर .... डिफ़ॉल्ट रूप से अपरिवर्तनीय माना जाना चाहिए।" - क्या?

— whatsisname

forअपरिवर्तनीय चर के साथ छोरों को चलाना बहुत कठिन है । फंक्शन में वेरिएबल को एनकैप्सुलेट करना आपके लिए पर्याप्त नहीं है? यदि आपको एक मात्र फ़ंक्शन में अपने चर का अनुसरण करने में परेशानी हो रही है, तो शायद आपके कार्य बहुत लंबे हैं।

— रॉबर्ट हार्वे

@RobertHarvey for (const auto thing : things)एक लूप के लिए है, और यह जो वैरिएबल पेश करता है वह (स्थानीय रूप से) अपरिवर्तनीय है। for i, thing in enumerate(things):यह भी किसी भी स्थानीय लोगों को उत्परिवर्तित नहीं करता

— केल

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

— डॉक्टर ब्राउन

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

— जोशुआ जोन्स

Answer 2

क्या यह एक गैर-resolvable धार्मिक संघर्ष है, या दोनों दिशाओं में अच्छे, उद्देश्य सॉफ़्टवेयर इंजीनियरिंग कारण हैं?

यह एक चीज है जो मुझे वास्तव में पसंद है (अच्छी तरह से लिखा गया) सी ++: आप देख सकते हैं कि क्या उम्मीद है। const string& x1एक निरंतर संदर्भ है, string x2एक प्रति है और const string x3एक निरंतर प्रति है। मुझे पता है कि फंक्शन में क्या होगा। बदल दिया x2 जाएगा , क्योंकि अगर यह नहीं थे, तो इसे गैर-कास्ट बनाने का कोई कारण नहीं होगा।

इसलिए यदि आपके पास एक ऐसी भाषा है जो इसे अनुमति देती है, तो घोषित करें कि आप मापदंडों के साथ क्या करने वाले हैं। इसमें शामिल सभी लोगों के लिए सबसे अच्छा विकल्प होना चाहिए।

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

Comments

एक और अच्छी बात यह है कि int f(const T x)और int f(T x)समारोह शरीर में केवल अलग हैं।

— Deduplicator

const int xकेवल स्पष्ट एक्स बनाने के लिए जैसे पैरामीटर के साथ एक C ++ फ़ंक्शन अंदर नहीं बदला गया है? मुझे बहुत ही अजीब अंदाज दिखता है।

— डॉक्टर ब्राउन

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

— nvoigt

@nvoigt: यदि कोई ("बाय-वैल्यू") फंक्शन पैरामीटर को संशोधित करना पसंद करता है, तो constयदि वह उसमें बाधा डालता है तो वह बस पैरामीटर सूची से दूर हट जाएगा। इसलिए मुझे नहीं लगता कि यह सवाल का जवाब देता है।

— डॉक ब्राउन

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

— nvoigt

Answer 3

हाँ, यह एक "धार्मिक संघर्ष" है, सिवाय इसके कि भगवान कार्यक्रमों (जहाँ तक मुझे पता है) को नहीं पढ़ते हैं, इसलिए यह पठनीयता के संघर्ष के लिए डाउनग्रेड है जो व्यक्तिगत निर्णय का विषय बन जाता है। और मैं निश्चित रूप से यह किया है, और यह किया है, दोनों तरीकों से देखा। उदाहरण के लिए,

शून्य प्रचार (OBJECT * ऑब्जेक्ट, डबल t0, डबल dt) {
  डबल टी = टी 0; / * t0 की स्थानीय प्रति इसके मूल्य को बदलने से बचने के लिए * /
  जबकि (जो भी) {
    timestep_the_object (...);
    t + = dt; }
  वापसी; }

इसलिए यहाँ, तर्क नाम t0 के कारण , मैं संभवतः इसके मूल्य को नहीं बदलना चाहूंगा। लेकिन इसके बजाय, हम केवल उस तर्क का नाम बदलकर tNow , या ऐसा कुछ करते हैं। तब मैं एक स्थानीय प्रति के बारे में बहुत अधिक-से-अधिक संभावना भूल गया और बस tNow + = dt लिखूं; उस आखिरी बयान के लिए।

लेकिन contrariwise, मान लीजिए मुझे पता था कि जिस क्लाइंट के लिए प्रोग्राम लिखा गया था, वह बहुत कम अनुभव वाले कुछ नए प्रोग्रामर को हायर करने वाला है, जो उस कोड को पढ़ रहे होंगे और काम कर रहे होंगे। तब मैं उन्हें पास-दर-मूल्य-भिन्नता के साथ भ्रमित करने की चिंता करूंगा, जबकि उनके दिमाग सभी व्यापारिक तर्क को पचाने में 100% व्यस्त हैं। इसलिए इस तरह के मामले में मैं हमेशा किसी भी तर्क की एक स्थानीय प्रति घोषित करूंगा, जिसे बदल दिया जाएगा, भले ही यह मेरे लिए अधिक या कम पठनीय हो।

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