जब आप इसे कॉल कर रहे हों, तो किसी फ़ंक्शन के पैरामीटर नामों को नहीं जानना


13

यहाँ एक प्रोग्रामिंग / भाषा समस्या है जिस पर मैं आपके विचार सुनना चाहता हूँ।

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

हालाँकि, एक समस्या है जो मुझे अभी तक किसी पर भी टिप्पणी करने की नहीं मिली है और वह हो सकता है कि यह सबसे बड़ा गुच्छा हो। जब आप किसी फ़ंक्शन को कॉल करते हैं तो यह अनाम होने की तर्कों की समस्या है।

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

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

func DrawRectangleClipped (rectToDraw, fillColor, clippingRect) {}

परिभाषा को देखते हुए, यदि फ़ंक्शन सही ढंग से लिखा गया है, तो यह पूरी तरह से स्पष्ट है कि क्या है। फ़ंक्शन को कॉल करते समय, आपके पास आपके आईडीई / संपादक में कुछ अंतर्मुखी / कोड पूरा होने वाला जादू भी हो सकता है जो आपको बताएगा कि अगला तर्क क्या होना चाहिए। लेकिन रुकें। अगर मुझे जरूरत है कि जब मैं वास्तव में कॉल लिख रहा हूं, तो क्या ऐसा कुछ नहीं है जो हम यहां याद कर रहे हैं? कोड पढ़ने वाले व्यक्ति को IDE का लाभ नहीं होता है और जब तक वे परिभाषा में नहीं जाते हैं, उन्हें पता नहीं होता है कि तर्क के रूप में पारित किए गए दो आयतों में से किसके लिए उपयोग किया जाता है।

समस्या इससे भी आगे जाती है। यदि हमारे तर्क कुछ स्थानीय चर से आते हैं, तो ऐसी स्थितियां हो सकती हैं, जहां हमें यह भी नहीं पता कि दूसरा तर्क क्या है क्योंकि हम केवल चर नाम देखते हैं। उदाहरण के लिए इस कोड की लाइन लें

DrawRectangleClipped(deserializedArray[0], deserializedArray[1], deserializedArray[2])

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

जैसा कि यह आमतौर पर प्रोग्रामिंग के साथ होता है, इस समस्या के कई संभावित समाधान हैं। कई पहले से ही लोकप्रिय भाषाओं में लागू हैं। उदाहरण के लिए C # में नामित पैरामीटर। हालाँकि, मुझे पता है कि सभी महत्वपूर्ण कमियां हैं। प्रत्येक फ़ंक्शन कॉल पर प्रत्येक पैरामीटर का नामकरण संभवत: पठनीय कोड के लिए नहीं हो सकता है। यह लगभग ऐसा लगता है कि शायद हम संभावनाओं को आगे बढ़ा रहे हैं जो सादे पाठ प्रोग्रामिंग हमें देता है। हम लगभग हर क्षेत्र में JUST पाठ से चले गए हैं, फिर भी हम अभी भी समान हैं। कोड में प्रदर्शित करने के लिए अधिक जानकारी की आवश्यकता है? अधिक पाठ जोड़ें। वैसे भी, यह थोड़ा पेचीदा हो रहा है इसलिए मैं यहां रुक जाऊंगा।

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

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

मैं वास्तव में इस पर नए दृष्टिकोण सुनना पसंद करूंगा। मुझे यकीन है कि मैं इस समस्या पर विचार करने वाला पहला व्यक्ति नहीं हूं, तो यह कैसे हल किया जाता है?


2
मैं उलझन में हूँ कि सटीक समस्या क्या है ... यहाँ कई विचार प्रतीत होते हैं, निश्चित नहीं कि कौन सा आपका मुख्य बिंदु है।
FrustratedWithFormsDesigner

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

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

1
@ बर्गी लोग शुद्ध एफपी में बहुत अधिक सामान्य करते हैं, इसलिए मुझे लगता है कि कार्य स्वयं आमतौर पर छोटे और अधिक होते हैं। मैं वैसे भी बंद हो सकता है। मुझे हास्केल और गिरोह के साथ वास्तविक परियोजनाओं पर काम करने का ज्यादा अनुभव नहीं है।
डार्विन

4
मुझे लगता है कि इसका जवाब "अपने चर का नाम 'deserializedArray' नहीं है"?
whatsisname

जवाबों:


10

मैं इस बात से सहमत हूं कि अक्सर जिस तरह से कार्यों का उपयोग किया जाता है वह लेखन कोड और विशेष रूप से पढ़ने के कोड का एक भ्रमित करने वाला हिस्सा हो सकता है।

इस समस्या का उत्तर आंशिक रूप से भाषा पर निर्भर करता है। जैसा कि आपने उल्लेख किया है, C # ने मापदंडों का नाम दिया है। इस समस्या के उद्देश्य-सी के समाधान में अधिक वर्णनात्मक विधि नाम शामिल हैं। उदाहरण के लिए, stringByReplacingOccurrencesOfString:withString:स्पष्ट मापदंडों के साथ एक विधि है।

ग्रूवी में, कुछ फ़ंक्शन मानचित्र लेते हैं, जो निम्नलिखित की तरह एक सिंटैक्स की अनुमति देता है:

restClient.post(path: 'path/to/somewhere',
            body: requestBody,
            requestContentType: 'application/json')

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

ऑब्जेक्टिव-सी जैसी भाषा में भी यह मापदंडों की संख्या को सीमित करने के लिए समझ में आता है। एक कारण यह है कि कई पैरामीटर वैकल्पिक हैं। एक उदाहरण के लिए, rangeOfString देखें: और में अपनी विविधताओं NSString

एक पैटर्न जिसे मैं अक्सर जावा में उपयोग करता हूं, वह एक धाराप्रवाह शैली के वर्ग को एक पैरामीटर के रूप में उपयोग करना है। उदाहरण के लिए:

something.draw(new Box().withHeight(5).withWidth(20))

यह एक पैरामीटर के रूप में एक वर्ग का उपयोग करता है, और एक धाराप्रवाह शैली वर्ग के साथ, आसानी से पठनीय कोड के लिए बनाता है।

उपरोक्त जावा स्निपेट भी मदद करता है जहां मापदंडों का क्रम इतना स्पष्ट नहीं हो सकता है। हम आम तौर पर निर्देशांक के साथ मानते हैं कि X, Y से पहले आता है। और मैं आमतौर पर एक सम्मेलन के रूप में चौड़ाई से पहले ऊँचाई देखता हूं, लेकिन यह अभी भी बहुत स्पष्ट नहीं है ( something.draw(5, 20))।

मैंने कुछ फ़ंक्शंस भी देखे हैं, drawWithHeightAndWidth(5, 20)लेकिन यहां तक ​​कि ये बहुत सारे पैरामीटर नहीं ले सकते हैं, या आप पठनीयता खोना शुरू कर देंगे।


2
आदेश, यदि आप जावा उदाहरण पर जारी रखते हैं, तो वास्तव में बहुत मुश्किल हो सकता है। उदाहरण के लिए, awt से निम्नलिखित कंस्ट्रक्टरों की तुलना करें: Dimension(int width, int height)और GridLayout(int rows, int cols)(पंक्तियों की संख्या ऊँचाई है, जिसका अर्थ GridLayoutहै पहले ऊँचाई और Dimensionचौड़ाई है)।
पियरे अरलाउड

1
इस तरह की विसंगतियों भी बहुत पीएचपी (साथ की आलोचना की है किया गया eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design :), उदाहरण के लिए array_filter($input, $callback)बनाम array_map($callback, $input), strpos($haystack, $needle)बनामarray_search($needle, $haystack)
पियरे ARLAUD

12

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

यह केवल विशेषणों का उपयोग करके वाक्य लिखने की कोशिश करने जैसा है। वहां अधिक क्रियाएं (फ़ंक्शन कॉल) डालें, अपनी सजा के लिए एक विषय (ऑब्जेक्ट) बनाएं, और इसे पढ़ना आसान है:

rect.clip(clipRect).fill(color)

यहां तक ​​कि अगर clipRectऔर colorभयानक नाम हैं (और उन्हें नहीं करना चाहिए), तो आप अभी भी संदर्भ से उनके प्रकारों को समझ सकते हैं।

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

(rect, clipRect, color) = deserializeClippedRect()
rect.clip(clipRect).fill(color)

बहुत सी पठनीय समस्याएं बहुत अधिक संक्षिप्त होने की कोशिश के कारण होती हैं, मध्यवर्ती चरणों को छोड़ देती हैं जो मनुष्यों को संदर्भ और शब्दार्थ की आवश्यकता होती है।


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

@ डार्विन IMHO ऐसा नहीं है कि प्रोग्रामिंग भाषा को अधिक प्राकृतिक-भाषा की तरह बनाकर इसमें सुधार किया जा सकता है। प्राकृतिक भाषाएँ बहुत अस्पष्ट हैं और हम उन्हें केवल संदर्भ में ही समझ सकते हैं और वास्तव में कभी सुनिश्चित नहीं हो सकते। स्ट्रिंग फ़ंक्शन को कॉल करना बेहतर होता है क्योंकि हर शब्द (आदर्श रूप से) में प्रलेखन और उपलब्ध स्रोत होते हैं और हमारे पास संरचना को स्पष्ट करने वाले कोष्ठक और बिंदु होते हैं।
Maaartinus

3

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

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


वाक्यांश वास्तव में एक कदम आगे की तरह लग रहे हैं। मुझे पता है कि कुछ भाषाओं में समान क्षमताएं हैं लेकिन यह व्यापक से एफएआर है। उल्लेख नहीं करने के लिए, सभी मैक्रो नफरत सी (++) से आने वाले शुद्धतावादियों के साथ जो कभी मैक्रोज़ का सही इस्तेमाल नहीं करते हैं, हमारे पास कभी भी लोकप्रिय भाषाओं में ऐसी विशेषताएं नहीं हो सकती हैं।
डार्विन

के सामान्य विषय में आपका स्वागत है डोमेन विशिष्ट भाषाओं , कुछ मैं वास्तव में चाहते हैं और अधिक लोगों का लाभ ... (+1) समझना होगा
Izkata

2

में जावास्क्रिप्ट (या ECMAScript ), उदाहरण के लिए, कई प्रोग्रामर के आदी बढ़ी

एकल अनाम वस्तु में नामित ऑब्जेक्ट गुणों के एक सेट के रूप में पैरामीटर पारित करना।

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

उदाहरण

फोन करने के बजाय

function drawRectangleClipped (rectToDraw, fillColor, clippingRect)

इस तरह:

drawRectangleClipped(deserializedArray[0], deserializedArray[1], deserializedArray[2])

, जो एक मान्य और सही शैली है, आप कॉल करते हैं

function drawRectangleClipped (params)

इस तरह:

drawRectangleClipped({
    rectToDraw: deserializedArray[0], 
    fillColor: deserializedArray[1], 
    clippingRect: deserializedArray[2]
})

, जो आपके प्रश्न के संबंध में वैध और सही और अच्छा है।

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


मैं वाक्य रचना को सत्यापित करने के लिए उस भाषा के बारे में पर्याप्त नहीं जानता लेकिन, मुझे यह पोस्ट पसंद आई। बहुत सुंदर लगता है। +1
आईटी एलेक्स

अक्सर, यह सामान्य तर्कों के साथ संयुक्त हो जाता है, यानी, 1-3 तर्क paramsहोते हैं (जैसे वैकल्पिक तर्क और अक्सर स्वयं वैकल्पिक) जैसे, यह फ़ंक्शन । इससे कई तर्कों के साथ कार्य करना आसान हो जाता है (उदाहरण के लिए 2 अनिवार्य और 6 विकल्प तर्क हैं)।
Maaartinus

0

आपको तब उद्देश्य-सी का उपयोग करना चाहिए, यहाँ एक फ़ंक्शन परिभाषा है:

- (id)performSelector:(SEL)aSelector withObject:(id)anObject withObject:(id)anotherObject

और यहाँ इसका उपयोग किया जाता है:

[someObject performSelector:someSelector withObject:someObject2 withObject:someObject3];

मुझे लगता है कि रूबी के समान निर्माण हैं और आप उन्हें कुंजी-मूल्य-सूचियों के साथ अन्य भाषाओं में अनुकरण कर सकते हैं।

जावा में जटिल कार्यों के लिए मैं कार्यों में डमी चर को परिभाषित करना पसंद करता हूं। आपके बाएं-दाएं उदाहरण के लिए:

Rectangle referenceRectangle = leftRectangle;
Rectangle targetRectangle = rightRectangle;
doSomeWeirdStuffWithRectangles(referenceRectangle, targetRectangle);

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


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

0

मेरा दृष्टिकोण अस्थायी स्थानीय चर बनाना है - लेकिन सिर्फ उन्हें कॉल न करें LeftRectangeऔर RightRectangle। बल्कि, मैं अधिक अर्थ व्यक्त करने के लिए कुछ लंबे नामों का उपयोग करता हूं। मैं अक्सर जितना संभव हो सके नामों को अलग करने की कोशिश करता हूं, उदाहरण के लिए something_rectangle, दोनों को कॉल न करें , अगर उनकी भूमिका बहुत सममित नहीं है।

उदाहरण (C ++):

auto& connector_source = deserializedArray[0]; 
auto& connector_target = deserializedArray[1]; 
auto& bounding_box = deserializedArray[2]; 
DoWeirdThing(connector_source, connector_target, bounding_box)

और मैं भी एक लाइनर आवरण समारोह या टेम्पलेट लिख सकते हैं:

template <typename T1, typename T2, typename T3>
draw_bounded_connector(
    T1& connector_source, T2& connector_target,const T3& bounding_box) 
{
    DoWeirdThing(connector_source, connector_target, bounding_box)
}

(यदि आप C ++ नहीं जानते हैं तो एम्परसेंड को अनदेखा करें)।

यदि फ़ंक्शन बिना किसी अच्छे विवरण के साथ कई अजीब चीजें करता है - तो संभवतः इसे फिर से बनाने की आवश्यकता है!

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.