स्वच्छ कोड: कुछ मापदंडों के साथ कार्य [बंद]

48

मैंने रॉबर्ट सी। मार्टिन द्वारा स्वच्छ संहिता के पहले अध्यायों को पढ़ा , और ऐसा लगता है कि यह बहुत अच्छा है, लेकिन मुझे संदेह है, एक भाग में यह उल्लेख किया गया है कि यह अच्छा है (संज्ञानात्मक) कि कार्यों के कुछ पैरामीटर होने चाहिए जितना संभव हो, यह भी पता चलता है कि 3 या अधिक पैरामीटर एक फ़ंक्शन के लिए बहुत अधिक है (जो मुझे बहुत अतिरंजित और आदर्शवादी लगता है), इसलिए मुझे आश्चर्य हुआ ...

दोनों वैश्विक चर का उपयोग करने और कार्यों पर कई तर्क देने की प्रथाएं खराब प्रोग्रामिंग प्रथाएं होंगी, लेकिन वैश्विक चर का उपयोग कार्यों में मापदंडों की संख्या को कम कर सकता है ...

इसलिए मैं सुनना चाहता था कि आप इसके बारे में क्या सोचते हैं, क्या यह फ़ंक्शन के मापदंडों की संख्या को कम करने के लिए वैश्विक चर का उपयोग करने के लायक है या नहीं? यह किन मामलों में होगा?

मुझे क्या लगता है कि यह कई कारकों पर निर्भर करता है:

स्रोत कोड का आकार
कार्यों के औसत में मापदंडों की संख्या।
कार्यों की संख्या।
आवृत्ति जिसमें समान चर का उपयोग किया जाता है।

मेरी राय में यदि स्रोत कोड का आकार अपेक्षाकृत छोटा है (जैसे कि कोड की 600 से कम लाइनें), तो कई कार्य हैं, एक ही चर को पैरामीटर के रूप में पारित किया जाता है और कार्यों के कई पैरामीटर होते हैं, फिर वैश्विक चर का उपयोग करने लायक होगा, लेकिन मैं क्या आप जानना चाहेंगे...

क्या आप मेरी राय साझा करते हैं?
आप अन्य मामलों के बारे में क्या सोचते हैं जहां स्रोत कोड बड़ा है, आदि?

पुनश्च । मैंने इस पोस्ट को देखा , शीर्षक बहुत समान हैं, लेकिन वह यह नहीं पूछता कि मैं क्या जानना चाहता हूं।

— OiciTrap
स्रोत

144

मुझे नहीं लगता कि विकल्प ग्लोबल्स होगा, लेकिन वस्तुओं में तर्कों को मजबूत करने के बजाय। यह शायद एक सुझाव का अधिक है जो postLetter(string country, string town, string postcode, string streetAddress, int appartmentNumber, string careOf)एक बदबूदार संस्करण है postLetter(Address address)। पुस्तक को पढ़ना जारी रखें, यह उम्मीद है कि ऐसा कुछ कहेगा।

— नाथन कूपर

3

@DocBrown मैंने सवाल उठाया है कि अंकल बॉब की तरह कुछ और मतलब है 3 डोर से अधिक का उपयोग न करें इसलिए मुझे वैश्विक चर का सही उपयोग करके उस समस्या का सामना करना पड़ता है? :-) मुझे लगता है कि लेखक को पता नहीं है कि इस समस्या को हल करने के लिए बेहतर तरीके हैं - जैसे नीचे दिए गए उत्तरों में उल्लेख किया गया है।

— बट्टेदेव

9

एन मापदंडों से अधिक नहीं अंगूठे का एक नियम है (एन के किसी भी मूल्य के लिए), एक हीरे पर etched नहीं। जनादेश के लिए अच्छी सलाह की गलती न करें मापदंडों के बहुत सारे आम तौर पर एक कोड गंध है कि आप एक समारोह / विधि में बहुत अधिक हो रहा है। लोग अतिरिक्त कॉल के अतिरिक्त ओवरहेड को चकमा देने के लिए कई कार्यों में विभाजित होने से बचते थे। कुछ अनुप्रयोग अब यह पूर्ण-गहन हैं और एक प्रोफाइलर आपको बता सकता है कि आपको कब और कहाँ अतिरिक्त कॉल से बचने की आवश्यकता है।

— जेरेड स्मिथ

14

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

— सुधाम

4

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

113

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

... उसी चर को मापदंडों के रूप में पारित किया जाता है

यह एक डिजाइन गंध हो सकता है। यदि आपके सिस्टम में अधिकांश कार्य करने के लिए समान पैरामीटर हैं, तो एक क्रॉस-कटिंग चिंता हो सकती है जिसे एक नया घटक शुरू करके नियंत्रित किया जाना चाहिए। मुझे नहीं लगता कि वैश्विक चर पेश करने के लिए उचित तर्क देने के लिए कई कार्यों के लिए एक ही चर को पारित करना।

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

— शमूएल
स्रोत

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

— OiciTrap

1

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

— शमूएल

96

अधिक पैरामीटर समझने के लिए एक सबरूटीन को कठिन बनाते हैं, वैश्विक चर पूरे कार्यक्रम को बनाते हैं, अर्थात सभी सबरूटीन्स को समझना कठिन होता है।

— जोर्ग डब्ल्यू मित्तग

2

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

— जेरी जेरेमियाह

6

इसका उत्तर सही है कि यह क्या कहता है, फिर भी ऐसा लगता है कि यह ओपी को "क्लीन कोड" में दिए गए पुनर्मिलन के बारे में गलतफहमी है। मुझे यकीन है कि उस पुस्तक में ग्लोबल्स द्वारा फ़ंक्शन मापदंडों को बदलने की कोई सिफारिश नहीं है।

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

68

आपको प्लेग जैसे वैश्विक चरों से बचना चाहिए ।

मैं (3 की तरह या 4) तर्क की संख्या के लिए एक हार्ड सीमा डाल नहीं है, लेकिन आप करते हैं उन्हें, कम से कम रखने के लिए यदि संभव हो तो चाहते हैं।

structचर का उपयोग करें (या C ++ में ऑब्जेक्ट्स) एक साथ एक ही इकाई में चर समूह के लिए और (संदर्भ द्वारा) कार्यों के लिए पास। आमतौर पर एक फ़ंक्शन को एक संरचना या वस्तु मिलती है (इसमें कुछ अलग चीजों के साथ) इसके साथ कुछ अन्य मापदंडों को जोड़ा जाता है जो फ़ंक्शन को कुछ करने के लिए कहते हैं struct।

अच्छी महक, स्वच्छ, मॉड्यूलर कोड के लिए, एकल जिम्मेदारी सिद्धांत से चिपके रहने की कोशिश करें । अपनी संरचना (या ऑब्जेक्ट), फ़ंक्शंस और स्रोत फ़ाइलों के साथ ऐसा करें। यदि आप ऐसा करते हैं, तो किसी फ़ंक्शन में दिए गए मापदंडों की प्राकृतिक संख्या स्पष्ट होगी।

— रॉबर्ट ब्रिस्टो-जॉनसन
स्रोत

5

एक संरचना में छिपे दसियों मापदंडों को पारित करने और उन्हें स्पष्ट रूप से पारित करने के बीच मुख्य अंतर क्या है?

— रुस्लान

21

@ रुसलान सामंजस्य।

— अबुजितिन गिलिफ़िर्का

9

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

— हंस ओल्सन

8

यह ठीक है, लेकिन आपको स्ट्रक्चर्स में सुसंगतता सुनिश्चित करनी होगी - सुनिश्चित करें कि एक स्ट्रक्चर्स में रखे गए पैरामीटर 'संबंधित' हैं। आप कुछ परिस्थितियों में एक से अधिक संरचना का उपयोग कर सकते हैं।

— एंड्रयू डोड्स

8

@abuzittingillifirca आपको स्वचालित रूप से सामंजस्य नहीं मिलता है। यदि किसी संरचना में मापदंडों को रखने का एकमात्र औचित्य उन्हें किसी विशेष कार्य के लिए पारित करना है, तो सामंजस्य शायद भ्रम है।

— सुधाम

55

हम संज्ञानात्मक भार के बारे में बात कर रहे हैं, वाक्य रचना नहीं। तो सवाल यह है कि ... इस संदर्भ में एक पैरामीटर क्या है ?

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

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

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

— क्वेंटिन
स्रोत

11

आपको +1 करने के लिए, यह एक शौचालय हो या एक कमोड हो जो वे समान हैं। भेड़ के कपड़ों में भेड़ियों की ओर इशारा करते हुए अच्छा काम।

— जेरेड स्मिथ

1

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

— ट्यूलेंस कोर्डोवा

4

बिल्कुल, एक वैश्विक चर एक छिपा हुआ पैरामीटर है।

— बिल के

+1 आपकी बात के लिए, मैंने MATLAB सिमुलेशन देखे हैं जो डेटा पास करने के लिए वैश्विक चर पर निर्भर हैं। परिणाम पूरी तरह से अपठनीय था क्योंकि यह बताना बहुत कठिन था कि कौन से चर किस फ़ंक्शन के पैरामीटर हैं।

— कॉर्ट अमोन

34

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

इसलिए जब आपके पास 600 से कम लाइनों के संदर्भ में राय है "वैश्विक चर का उपयोग करना इसके लायक होगा" , तो आप पूरी तरह से अंकल बॉब की राय साझा करते हैं। बेशक, यह बहस योग्य है अगर "अधिकतम 3 पैरामीटर" आदर्श संख्या है, और यदि यह नियम कभी-कभी बहुत से सदस्य चर भी छोटी कक्षाओं में ले जाता है। IMHO यह एक व्यापार बंद है, जहां लाइन खींचने के लिए कोई कठिन-और-तेज नियम नहीं है।

— डॉक्टर ब्राउन
स्रोत

10

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

— jpmc26

2

@ jpmc26: यदि केवल कक्षाएं बहुत बड़ी हो जाती हैं और बहुत अधिक सदस्य चर प्राप्त हो जाते हैं, तो इसका परिणाम "जटिलता का एक बड़ा रूप" हो जाता है, इसलिए इसका परिणाम किसी भी अधिक नहीं होता है।

— डॉक ब्राउन

4

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

— jpmc26

3

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

— इजाकाटा

3

+1 स्पष्ट रूप से कहने के लिए कि सदस्य चर वैश्विक चर नहीं हैं। बहुत से लोग सोचते हैं कि वे हैं।

— ट्यूलेंस कोर्डोवा

34

कई मापदंडों को अवांछनीय माना जाता है, लेकिन उन्हें खेतों या वैश्विक चर में बदलना बहुत बुरा है क्योंकि यह वास्तविक समस्या को हल नहीं करता है बल्कि नई समस्याओं को हल करता है।

कई मापदंडों का होना अपने आप में समस्या नहीं है, लेकिन यह एक लक्षण है कि आपको समस्या हो सकती है। इस विधि पर विचार करें:

Graphics.PaintRectangle(left, top, length, height, red, green, blue, transparency);

7 पैरामीटर होने पर एक निश्चित चेतावनी संकेत है। अंडरलिंग समस्या यह है कि ये पैरामीटर स्वतंत्र नहीं हैं, लेकिन समूहों में हैं। leftऔर topएक Positionसंरचना के रूप में एक साथ होते हैं , lengthऔर heightएक Sizeसंरचना के रूप में red, blueऔर greenएक Colorसंरचना के रूप में । और शायद Colorऔर पारदर्शिता एक Brushसंरचना में है? शायद Positionऔर Sizeएक Rectangleसंरचना में एक साथ है , जिस स्थिति में हम इसे वस्तु Paintपर एक विधि में बदलने पर भी विचार कर सकते हैं Rectangle? तो हम इसके साथ समाप्त हो सकते हैं:

Rectangle.Paint(brush);

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

Graphics.left = something;
Graphics.top = something;
Graphics.length = something;
...etc
Graphics.PaintRectangle();

यहां हमने पैरामीटर की संख्या में समान कमी हासिल की है, लेकिन हमने वास्तव में डिजाइन को बदतर बना दिया है ।

नीचे की रेखा: किसी भी प्रोग्रामिंग सलाह और नियमों के लिए, अंतर्निहित तर्क को समझना वास्तव में महत्वपूर्ण है।

— JacquesB
स्रोत

4

+1 अच्छा, रचनात्मक, समझने योग्य, गैर-सैद्धांतिक उत्तर।

— एनओई

1

उल्लेख नहीं करने के लिए, नरक क्या है आपका "वर्ग" लंबाई और ऊंचाई दोनों की विशेषता है। :)

— वाइल्डकार्ड

1

+1 स्वीकार करने के लिए कि स्पष्ट तीसरा तरीका कुछ जवाबों से निहित है (यानी फ़ंक्शन कॉल से पहले कुछ संरचना / वस्तु को कई असाइनमेंट) कोई बेहतर नहीं है।

— बेनजीज़

@Wildcard: धन्यवाद, मुद्दे को भ्रमित करने से बचने के लिए इसे "आयत" में बदल दिया!

— जैक्सबी जुएल

7

यह कार्यों के मापदंडों की संख्या को कम करने के लिए वैश्विक चर का उपयोग करने के लायक है या नहीं?

नहीं

मैंने इस पुस्तक के पहले अध्याय को पढ़ा

क्या आपने बाकी किताब पढ़ी?

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

एक पैरामीटर क्या है?

यह सामान है। एक अच्छी तरह से लेबल बॉक्स में। इससे कोई फर्क नहीं पड़ता कि आपके पास कितने बॉक्स हैं जब आप इसमें जो भी सामान डाल सकते हैं?

यह शिपिंग और हैंडलिंग की लागत है।

Move(1, 2, 3, 4)

मुझे बताओ कि तुम पढ़ सकते हो। जाओ, कोशिश करो।

Move(PointA, PointB)

इसीलिए।

उस ट्रिक को परिचय पैरामीटर ऑब्जेक्ट कहा जाता है ।

और हाँ यह सिर्फ एक ट्रिक है अगर आप सभी कर रहे हैं तो पैरामीटर की गिनती कर रहे हैं। आपको जो गिनना चाहिए वह IDEAS है! कपोल-कल्पना! आप मुझे एक बार में कितना सोचने पर मजबूर कर रहे हैं? इसे सरल रखें।

अब यह एक ही गिनती है:

Move(xyx, y)

ओउ! यह खराब है! यहां क्या गलत हुआ?

यह विचारों की संख्या को सीमित करने के लिए पर्याप्त नहीं है। उनके स्पष्ट विचार होने चाहिए। एक बिल्ली xyx क्या है?

अब भी यह कमजोर है। इस बारे में सोचने के लिए और अधिक शक्तिशाली तरीका क्या है?

कार्य छोटा होना चाहिए। इससे छोटा कोई नहीं।

चाचा बॉब

Move(PointB)

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

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

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

— candied_orange
स्रोत

3

"क्या आपने बाकी किताब पढ़ी?" आपके प्रश्न का उत्तर मेरी पोस्ट के पहले 8 शब्दों में दिया गया है ...

— OiciTrap

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

— बिल के

2

इस उत्तर के स्वर में सुधार किया जा सकता था। यह बहुत अचानक और कठोर के रूप में पढ़ता है। उदाहरण के लिए: "मुझे बताओ कि तुम पढ़ सकते हो। जाओ, कोशिश करो।" बहुत आक्रामक दिखाई देता है और "ऊपर / नीचे दो फ़ंक्शन कॉल" के रूप में फिर से लिखा जा सकता है, जिसे पढ़ना आसान है? " आपको आक्रमण के बिना बिंदु को पाने की कोशिश करनी चाहिए। ओपी सिर्फ सीखने की कोशिश कर रहा है।

— काइल ए

मत भूलना ओपी भी जागते रहने की कोशिश कर रहा है।

— कैंडिड_ऑरेंज

4

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

दूसरी ओर पैरामीटर पारित करना, केवल अपने स्वयं के फ़ंक्शन के लिए चर के दायरे को सीमित करता है जैसे कि केवल फ़ंक्शन अपने पैरामीटर को एक बार कॉल कर सकता है।

यदि आपको पैरामीटर के बजाय वैश्विक चर पास करने की आवश्यकता है, तो कोड को फिर से डिज़ाइन करना बेहतर होगा।

केवल मेरे दो सेंट्स।

— Dimos
स्रोत

"मैं मापदंडों को कम करने के लिए वैश्विक चर का उपयोग कभी नहीं करूंगा" पूरी तरह से सहमत हूं। यह अनावश्यक युग्मन बनाता है।

— बट्टेदेव

2

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

यदि आप OO भाषा में किसी विधि में 3 से अधिक का उपयोग कर रहे हैं, तो आपको विचार करना चाहिए कि परमार्थ एक दूसरे से किसी भी तरह से संबंधित नहीं हैं और इसलिए आपको इसके बजाय वास्तव में एक वस्तु में गुजरना चाहिए?

इसके अलावा, यदि आप अधिक (छोटे) फ़ंक्शन बनाते हैं, तो आप यह भी देखेंगे कि फ़ंक्शंस में अधिक बार 3 पैरा या कम होते हैं। निकालें समारोह / विधि अपने दोस्त है :-)।

वैश्विक चर का उपयोग न करें अधिक गोल होने के तरीके के रूप में! यह एक और भी बुरा एक के लिए एक बुरा अभ्यास गमागमन है!

— bytedev
स्रोत

1

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

साधारण मामलों में यह एक साधारण डीटीओ है जिसमें गुणों के रूप में पुराने मापदंडों के अलावा कुछ भी नहीं है।

— टिमोथी ट्रक
स्रोत

1

वैश्विक चर का उपयोग करना हमेशा कोड के लिए एक आसान तरीका लगता है (विशेष रूप से एक छोटे कार्यक्रम में), लेकिन यह आपके कोड को विस्तारित करने में मुश्किल बना देगा।

हां, आप एक इकाई में मापदंडों को बांधने के लिए एक सरणी का उपयोग करके किसी फ़ंक्शन में मापदंडों की संख्या को कम कर सकते हैं।

function <functionname>(var1,var2,var3,var4.....var(n)){}

उपरोक्त फ़ंक्शन को संपादित किया जाएगा और [सहयोगी सरणी का उपयोग करके] में बदल दिया जाएगा -

data=array(var1->var1,
           var2->var2
           var3->var3..
           .....
           ); // data is an associative array

function <functionname>(data)

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

— नरेंद्र परमार
स्रोत

1

PHP 4 से एक उदाहरण लेते हुए, इसके लिए फ़ंक्शन हस्ताक्षर देखें mktime():

int mktime ([ int $hour = date("H") [, int $minute = date("i") [, int $second = date("s") [, int $month = date("n") [, int $day = date("j") [, int $year = date("Y") [, int $is_dst = -1 ]]]]]]] )

क्या आपको वह भ्रमित नहीं लगता? फ़ंक्शन को "मेक टाइम" कहा जाता है, लेकिन इसमें दिन, महीने और साल के मापदंडों के साथ-साथ तीन समय के पैरामीटर भी होते हैं। यह याद रखना कितना आसान है कि वे किस क्रम में जाते हैं? अगर आप देख लें तो क्या होगा mktime(1, 2, 3, 4, 5, 2246);? क्या आप समझ सकते हैं कि बिना किसी और चीज़ का हवाला दिए? क्या 2246२४ घंटे के समय की व्याख्या "२२:४६" के रूप में की जाती है? अन्य मापदंडों का क्या मतलब है? यह एक वस्तु के रूप में बेहतर होगा।

PHP 5 पर चलते हुए, अब एक DateTime ऑब्जेक्ट है। इसके तरीकों के बीच दो setDate()और कहा जाता है setTime()। उनके हस्ताक्षर निम्नानुसार हैं:

public DateTime setDate ( int $year , int $month , int $day )
public DateTime setTime ( int $hour , int $minute [, int $second = 0 ] )

आपको अभी भी याद रखना होगा कि मापदंडों का क्रम सबसे बड़ा से सबसे छोटा होता है, लेकिन यह एक बड़ा सुधार है। ध्यान दें कि एक एकल विधि नहीं है जो आपको एक ही बार में सभी छह पैरामीटर सेट करने की अनुमति देती है। ऐसा करने के लिए आपको दो अलग-अलग कॉल करने होंगे।

चाचा बॉब किस बारे में बात कर रहे हैं, एक सपाट संरचना होने से बच रहे हैं। संबंधित मापदंडों को एक वस्तु में एक साथ वर्गीकृत किया जाना चाहिए, और यदि आपके पास तीन से अधिक पैरामीटर हैं, तो यह बहुत संभावना है कि आपको वहां एक छद्म वस्तु मिल गई है, जो आपको अधिक अलगाव के लिए एक उपयुक्त वस्तु बनाने का अवसर देती है। हालाँकि PHP में एक अलग Dateऔर Timeवर्ग नहीं है, आप विचार कर सकते हैं कि DateTimeवास्तव में एक Dateवस्तु और एक Timeवस्तु है।

आपके पास संभवतः निम्न संरचना हो सकती है:

<?php
$my_date = new Date;
$my_date->setDay(5);
$my_date->setMonth(4);
$my_date->setYear(2246);

$my_time = new Time;
$my_time->setHour(1);
$my_time->setMinute(2);
$my_time->setSecond(3);

$my_date_time = new DateTime;
$my_date_time->setTime($my_time);
$my_date_time->setDate($my_date);
?>

क्या हर बार दो या तीन पैरामीटर सेट करना अनिवार्य है? यदि आप केवल घंटे या सिर्फ दिन बदलना चाहते हैं, तो अब ऐसा करना आसान है। हां, ऑब्जेक्ट को यह सुनिश्चित करने के लिए मान्य किया जाना चाहिए कि प्रत्येक पैरामीटर दूसरों के साथ काम करता है, लेकिन वैसे भी पहले ऐसा ही था।

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

ओह, और ग्लोबल्स का उपयोग न करें!

— सीजे डेनिस
स्रोत

1

यहाँ अच्छे जवाब के बहुत सारे अभी तक बात को संबोधित नहीं कर रहे हैं। अंगूठे के ये नियम क्यों? यह गुंजाइश के बारे में है, यह निर्भरता के बारे में है और यह उचित मॉडलिंग के बारे में है।

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

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

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

अधिक बार आप दूसरे समाधान के साथ जाते हैं और अधिक महंगा रखरखाव आगे होने वाला है और कठिन और अनाकर्षक एक रिफ्लेक्टर बन जाएगा।

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

— मार्टिन मात
स्रोत

0

कई बार मैंने पाया है कि बहुत सारे मापदंडों को समूहीकृत करना जिन्हें एक साथ बेहतर चीजों को भेजा गया था।

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

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

— Borjab
स्रोत

0

पूरे सम्मान के साथ, मुझे पूरा यकीन है कि आप किसी फ़ंक्शन में बहुत कम पैरामीटर होने के बिंदु से पूरी तरह से चूक गए हैं।

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

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

मूल्यों के बजाय वस्तुओं को पारित करने से, शायद आप अपने मस्तिष्क के लिए अमूर्तता का एक स्तर प्राप्त करते हैं क्योंकि अब इसे हां का एहसास करने की आवश्यकता है , मुझे उन खोज गुणों के भीतर होने वाले 15 गुणों के बारे में सोचने के बजाय यहां काम करने के लिए एक SearchContext मिला है ।

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

अब केवल कार्य स्तर पर काम करने के बजाय, आपको अपनी परियोजना के वैश्विक दायरे पर विचार करने की आवश्यकता है (गव्ड, कितना भयानक! मैं कंपकंपी ...)। आपके पास फ़ंक्शन (बकवास, वह वैश्विक चर नाम क्या है?) में आपके सामने आपकी सारी जानकारी भी नहीं है (मुझे आशा है कि जब से मैंने इस फ़ंक्शन को कॉल किया है, तब इसे किसी और चीज़ से नहीं बदला गया है)।

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

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

संपूर्ण आदर्श चीजों को प्रबंधित करना आसान है, और वैश्विक चर ऐसा नहीं करने जा रहे हैं। मैं यहाँ तक कहूँगा कि वे सबसे बुरी चीजों में से एक हैं जो आप विपरीत दिशा में जाने के लिए कर सकते हैं।

— jleach
स्रोत

-1

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

जब आपको कई मापदंडों की आवश्यकता होती है: एकल ऑब्जेक्ट / हैश या ऐरे का उपयोग करें।

मेरे साथ सहन, मैं वादा करता हूँ कि मैं ट्रोलिंग नहीं कर रहा हूँ ...

इससे पहले कि आप कहते हैं कि "क्या अच्छा है एक एकल परम फूंक?" या "1 एरे और मल्टी प्लेग के बीच अंतर है?"

सही है। यह शायद नेत्रहीन सूक्ष्म है, लेकिन अंतर कई गुना है - मैं यहां कई लाभों का पता लगाता हूं

जाहिरा तौर पर कुछ ppl लगता है कि 3 तर्क का सही # है। कुछ लोग सोचते हैं कि 2. ठीक है, यह सवाल अभी भी भीख माँगता है, "कौन सा पैराग्राफ arg [0] में जाता है?" विकल्प को चुनने के बजाय जो इंटरफ़ेस को अधिक कठोर घोषणा के साथ संकुचित करता है।

मुझे लगता है कि मैं अधिक कट्टरपंथी स्थिति के लिए बहस करता हूं: स्थिति संबंधी तर्कों पर भरोसा नहीं करता। मुझे लगता है कि यह नाजुक है और लानत तर्कों की स्थिति के बारे में तर्क देता है। इसे छोड़ें और कार्यों और चर के नामों के बारे में अपरिहार्य लड़ाई के साथ दाईं ओर जाएं। 😉

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

function sendMessage({toUser, fromUser, subject, body}) { }

// And call the method like so:
sendMessage({toUser: this.parentUser, fromUser: this.currentUser, subject: ‘Example Alert’})

— दान लेवी
स्रोत

6

तर्क नाम की फ़ेकिंग वास्तव में केवल एक तर्क नहीं है।

— JDługosz

अगर मैं एक लक्ष्य हासिल कर लेता हूं तो यह "फेकिंग" क्यों है? मैं नामित तर्कों पर एक उच्च प्राथमिकता दे रहा हूं। क्योंकि पोजिशनल आर्गल्स कॉलिंग कोड के लिए स्पष्ट नहीं हैं, और # नामित कार्यों के साथ एक देव को यह याद रखना आवश्यक है कि यह याद रखने में मददगार नहीं है कि कौन से परेम कहाँ और कौन से वैकल्पिक हैं। ... आखिरकार आप वैकल्पिक, सौभाग्य के बाद उस कार्ड के घर के दस्तावेज और अपग्रेड करने के लिए एक आवश्यक परम जोड़ना चाहते हैं।

— डैन लेवी

2

नामित पैरामेट्स भी एक सुदृढीकरण सीखने की चाल है - मनुष्य शब्दों के संग्रह के लिए अधिक अर्थ संलग्न करता है।

— डेन लेवी