आवश्यक नहीं होने पर भी वैकल्पिक पैरामीटर नाम निर्दिष्ट करें?

25

निम्नलिखित विधि पर विचार करें:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{

}

और निम्नलिखित कॉल:

var ids = ReturnEmployeeIds(true);

सिस्टम के लिए एक डेवलपर नए के लिए, यह अनुमान लगाना बहुत मुश्किल होगा कि trueउसने क्या किया। पहली बात यह है कि आप विधि नाम पर होवर करें या परिभाषा पर जाएं (जिनमें से कोई भी बड़े काम थोड़े ही हैं)। लेकिन, पठनीयता के लिए, क्या यह लिखने के लिए समझ में आता है:

var ids = ReturnEmployeeIds(includeManagement: true);

क्या कहीं भी ऐसा है, औपचारिक रूप से चर्चा करता है कि कंपाइलर की आवश्यकता नहीं होने पर वैकल्पिक मापदंडों को स्पष्ट रूप से निर्दिष्ट करना है या नहीं?

निम्नलिखित लेख कुछ कोडिंग सम्मेलनों पर चर्चा करता है: https://msdn.microsoft.com/en-gb/library/ff926074.aspx

ऊपर दिए गए लेख के समान कुछ महान होगा।

c# coding-style readability parameters

— JᴀʏMᴇᴇ
स्रोत

2

ये दो नहीं बल्कि असंबंधित प्रश्न हैं: (1) क्या आपको स्पष्टता के लिए वैकल्पिक तर्क लिखना चाहिए? (२) क्या एक booleanविधि तर्क का उपयोग करना चाहिए , और कैसे?

— किलन फथ

5

यह सब व्यक्तिगत पसंद / शैली / राय को उबालता है। निजी तौर पर, मुझे पैरामीटर के नाम पसंद हैं, जब मूल्य पास किया गया एक शाब्दिक है (एक चर पहले से ही अपने नाम के माध्यम से पर्याप्त जानकारी दे सकता है)। लेकिन, यह मेरी निजी राय है।

— मेटाफाइट

1

शायद उस लिंक को अपने प्रश्न में एक उदाहरण स्रोत के रूप में शामिल करें?

— मेटाफ़ाइट

4

यदि यह कुछ भी जोड़ता है, तो मैंने इसे स्टाइलकॉप और रीशर के माध्यम से चलाया - न तो इस पर कोई स्पष्ट दृष्टिकोण था। ReSharper का कहना है कि नामित पैरामीटर को हटाया जा सकता है और फिर कहा जाता है कि एक नामित पैरामीटर जोड़ा जा सकता है। मेरे विचार से एक कारण के लिए सलाह मुफ्त है ...: - /

— रॉबी डी

4

पठनीय सहायता के रूप

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

28

मैं कहूंगा कि C # दुनिया में, एक एनम यहां सबसे अच्छे विकल्पों में से एक होगा।

इसके साथ ही आप यह समझने के लिए मजबूर होंगे कि आप क्या कर रहे हैं और कोई भी उपयोगकर्ता व्हाट्सऐप देख रहा है। यह भविष्य के एक्सटेंशन के लिए भी सुरक्षित है;

public enum WhatToInclude
{
    IncludeAll,
    ExcludeManagement
}

var ids = ReturnEmployeeIds(WhatToInclude.ExcludeManagement);

तो, यहाँ मेरी राय में:

enum> वैकल्पिक एनुम> वैकल्पिक बूल

संपादित करें: तेंदुए के साथ चर्चा करने के कारण नीचे [Flags]Enum के बारे में जो इस विशिष्ट मामले में एक अच्छा फिट हो सकता है (क्योंकि हम विशेष रूप से चीजों को शामिल करने / बाहर करने के बारे में बात कर रहे हैं), मैं इसके बजाय ISet<WhatToInclude>एक पैरामीटर के रूप में उपयोग करने का प्रस्ताव देता हूं ।

यह कई फायदे के साथ एक "आधुनिक" अवधारणा है, ज्यादातर इस तथ्य से उपजी है कि यह संग्रह के LINQ परिवार में फिट बैठता है, लेकिन इसमें भी [Flags]अधिकतम 32 समूह हैं। उपयोग करने ISet<WhatToInclude>का मुख्य पहलू यह है कि C # सिंटैक्स में कितनी बुरी तरह सेट का समर्थन किया जाता है:

var ids = ReturnEmployeeIds(
    new HashSet<WhatToInclude>(new []{ 
        WhatToInclude.Cleaners, 
        WhatToInclude.Managers});

सेट के निर्माण के लिए और "शॉर्टकट सेट" जैसे कि बनाने के लिए, इसमें से कुछ को सहायक कार्यों से कम किया जा सकता है

var ids = ReturnEmployeeIds(WhatToIncludeHelper.IncludeAll)

— NiklasJ
स्रोत

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

— दान नीली

3

मैं की तरह enumदृष्टिकोण है, लेकिन मैं मिश्रण का एक बड़ा प्रशंसक नहीं हूँ Includeऔर Excludeएक ही में enumयह समझ क्या हो रहा है और अधिक कठिन है के रूप में। यदि आप चाहते हैं कि यह वास्तव में एक्स्टेंसिबल हो, तो आप इसे एक बना सकते हैं [Flags] enum, उन सभी को बना सकते हैं IncludeXxx, और एक IncludeAllसेट प्रदान कर सकते हैं Int32.MaxValue। फिर आप 2 ReturnEmployeeIdsओवरलोड प्रदान कर सकते हैं - एक जो सभी कर्मचारियों को लौटाता है , और एक जो एक WhatToIncludeफिल्टर पैरामीटर लेता है जो कि एनम झंडे का संयोजन हो सकता है।

— लेपर्सस्किनपिलबॉक्स हॅट

@LasterSkinPillBoxHat ठीक है, मैं बाहर / शामिल पर सहमत हूं। इसलिए यह एक छोटा सा उदाहरण है, लेकिन मैं इसे इनक्लूजमेंट कह सकता हूं। आपके अन्य बिंदु पर, मैं सहमत नहीं हूं - मुझे लगता [Flags]है कि यह एक अवशेष है और केवल विरासत या प्रदर्शन कारणों के लिए उपयोग किया जाना चाहिए। मुझे लगता है कि ISet<WhatToInclude>यह एक बहुत ही बेहतर अवधारणा है (दुर्भाग्यवश C # में कुछ सिंथैटिक शुगर की कमी है, जिसका उपयोग करना अच्छा है)।

— निकलेसज

@NiklasJ - मुझे Flagsदृष्टिकोण पसंद है क्योंकि यह कॉलर को पास करने की अनुमति देता है WhatToInclude.Managers | WhatToInclude.Cleanersऔर बिटवाइज़ या बिल्कुल व्यक्त करता है कि कॉलर इसे कैसे संसाधित करेगा (अर्थात प्रबंधक या क्लीनर)। सहज ज्ञान युक्त

— शकरकंद

@LeopardSkinPillBoxHat बिल्कुल, लेकिन यह उस पद्धति का एकमात्र उल्टा है। डाउनसाइड्स में उदाहरण के लिए सीमित संख्या में विकल्प और अन्य लाइनक जैसी अवधारणाओं के साथ संगत नहीं होना शामिल है।

— निकलेसज

20

क्या यह लिखने के लिए समझ में आता है:
 var ids=ReturnEmployeeIds(includeManagement: true);

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

 bool includeManagement=true;
 var ids=ReturnEmployeeIds(includeManagement);

नामित पैरामीटर संस्करण की तुलना में यह शैली संभवतः C # प्रोग्रामर के बीच अधिक सामान्य है, क्योंकि संस्करण 4.0 से पहले नामित पैरामीटर भाषा का हिस्सा नहीं थे। पठनीयता पर प्रभाव लगभग समान है, इसे केवल कोड की एक अतिरिक्त पंक्ति की आवश्यकता है।

तो मेरी सिफारिश: यदि आपको लगता है कि अलग-अलग नामों के साथ एक एनम या दो फ़ंक्शन का उपयोग करना "ओवरकिल" है, या आप एक अलग कारण के लिए हस्ताक्षर को बदलना या नहीं करना चाहते हैं, तो आगे बढ़ें और नामित पैरामीटर का उपयोग करें।

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

यह ध्यान रखना चाहते हैं कि आप दूसरे उदाहरण पर अतिरिक्त मेमोरी का उपयोग कर रहे हैं

— अल्वारो

10

@ अलवरो ऐसे तुच्छ मामले में सच होने की संभावना नहीं है (जहां चर का एक स्थिर मूल्य है)। अगर ऐसा था भी, तो शायद ही यह ध्यान देने योग्य है। हम में से अधिकांश इन दिनों 4KB RAM पर नहीं चल रहे हैं।

— क्रिस हेस

3

क्योंकि यह C # है, आप includeManagementस्थानीय के रूप में चिह्नित कर सकते हैं constऔर किसी भी अतिरिक्त मेमोरी का उपयोग करने से बच सकते हैं।

— जैकब क्राल

8

दोस्तों, मैं अपने जवाब में ऐसा कोई भी सामान नहीं जोड़ने जा रहा हूँ जो केवल मेरे विचार से महत्वपूर्ण हो सकता है।

— डॉक ब्राउन

17

यदि आप कोड का सामना करते हैं जैसे:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{

}

आप बहुत गारंटी दे सकते हैं कि अंदर क्या {}होगा कुछ इस तरह होगा:

public List<Guid> ReturnEmployeeIds(bool includeManagement = false)
{
    if (includeManagement)
        return something
    else
        return something else
}

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

public List<Guid> GetNonManagementEmployeeIds()
{

}

public List<Guid> GetAllEmployeeIds()
{

}

यह दोनों कोड की पठनीयता में सुधार करता है और यह सुनिश्चित करता है कि आप SOLID सिद्धांतों का बेहतर पालन कर रहे हैं।

EDIT जैसा कि टिप्पणियों में बताया गया है, इन दो तरीकों की संभावना यहाँ के मामले में साझा कार्यक्षमता होगी, और यह साझा कार्यक्षमता संभवतः एक निजी फ़ंक्शन में लिपटेगी, जो इसके कुछ पहलुओं को नियंत्रित करने के लिए बूलियन पैरामीटर की आवश्यकता होगी। ।

इस मामले में, क्या पैरामीटर नाम की आपूर्ति की जानी चाहिए, भले ही संकलक को इसकी आवश्यकता न हो? मेरा सुझाव है कि उस मामले पर कोई सरल जवाब नहीं है और उस मामले में केस के आधार पर निर्णय की आवश्यकता है:

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

public List<Guid> GetNonManagementEmployeeIds()
{
    return ReturnEmployeeIds(true);
}

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

— डेविड अरनो
स्रोत

12

मैं सुनता हूं कि आप क्या कह रहे हैं, लेकिन आप जो पूछ रहे हैं, उस बिंदु को याद करने की जरूरत है। एक परिदृश्य जिससे यह मान लिया जाये कि है , सबसे वैकल्पिक पैरामीटर (इन परिदृश्यों मौजूद है) का उपयोग करने के लिए उपयुक्त यह पैरामीटर नाम के लिए भले ही यह अनावश्यक है ठीक है?

— J --Mᴇᴇ

4

सभी सच है, लेकिन सवाल इस तरह के एक कॉल के बारे में था । इसके अलावा एक ध्वज पैरामीटर विधि के भीतर एक शाखा की गारंटी नहीं देता है। यह बस एक और परत पर पारित किया जा सकता है।

— रॉबी डे

यह गलत नहीं है, लेकिन ओवरसिंपलिंग है। वास्तविक कोड में, आप पाएंगे

public List<Guid> ReturnEmployeeIds(bool includeManagement) {   calculateSomethingHereForBothBranches;     if (includeManagement)         return something     else         return something else }

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

— डॉक ब्राउन

4

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

— मेटाफ़ाइट

1

मैं व्यवहार के लिए 3 मामलों की कल्पना कर सकता हूं जो दो कार्यों के बीच भिन्न हैं। 1. पूर्व-प्रसंस्करण है जो अलग है। निजी फ़ंक्शन में सार्वजनिक कार्यों को पूर्व-प्रक्रिया तर्क दें। 2. पोस्ट-प्रोसेसिंग है जो अलग है। निजी फ़ंक्शन से सार्वजनिक कार्यों को पोस्ट-प्रोसेस करें। 3. मध्यवर्ती व्यवहार होता है जो भिन्न होता है। यह निजी समारोह के लिए एक मेमने के रूप में पारित किया जा सकता है, यह मानते हुए कि आपकी भाषा इसका समर्थन करती है। अक्सर बार, यह एक नया पुन: प्रयोज्य अमूर्त की ओर जाता है जो वास्तव में आपके पहले नहीं हुआ था।

— jpmc26

1

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

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

उदाहरण के लिए, यह एक कॉल को स्पष्ट करने में मदद कर सकता है, लेकिन जरूरी नहीं कि दूसरा हो।

एक नामित तर्क यहां मददगार हो सकता है:

var ids = ReturnEmployeeIds(includeManagement: true);

अधिक अतिरिक्त स्पष्टता न जोड़ें (मैं अनुमान लगाने जा रहा हूं कि यह एक पहेली है):

Enum.Parse(typeof(StringComparison), "Ordinal", ignoreCase: true);

यह वास्तव में स्पष्टता को कम कर सकता है (यदि कोई व्यक्ति यह नहीं समझता है कि किसी सूची में क्या क्षमता है):

var employeeIds = new List<int>(capacity: 24);

या जहां यह कोई फर्क नहीं पड़ता क्योंकि आप अच्छे चर नामों का उपयोग कर रहे हैं:

bool includeManagement = true;
var ids = ReturnEmployeeIds(includeManagement);

क्या कहीं भी ऐसा है, औपचारिक रूप से चर्चा करता है कि कंपाइलर की आवश्यकता नहीं होने पर वैकल्पिक मापदंडों को स्पष्ट रूप से निर्दिष्ट करना है या नहीं?

AFAIK नहीं। चलो हालांकि दोनों भागों को संबोधित करते हैं: केवल समय जब आपको नामांकित मापदंडों का स्पष्ट रूप से उपयोग करने की आवश्यकता होती है क्योंकि संकलक को आपको ऐसा करने की आवश्यकता होती है (आमतौर पर यह कथन अस्पष्टता को दूर करने के लिए होता है)। तो इसके अलावा आप जब चाहें उनका उपयोग कर सकते हैं। एमएस के इस लेख में कुछ सुझाव दिए गए हैं, जब आप उनका उपयोग करना चाहते हैं, लेकिन यह विशेष रूप से निश्चित नहीं है https://msdn.microsoft.com/en-us/library/dd264739.aspx ।

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

टी एल; डॉ

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

0

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

साथ ReturnEmployeeIds(true), जैसे तुमने कहा था, जब तक आप समारोह की घोषणा / प्रलेखन को देखो यह असंभव आंकड़ा करने के लिए क्या trueमतलब है - तो आप चाहिए नामित पैरामीटर सिंटैक्स का उपयोग करें।

अब इस तीसरे मामले पर विचार करें:

void PrintEmployeeNames(bool includeManagement) {
    foreach (id; ReturnEmployeeIds(includeManagement)) {
        Console.WriteLine(ReturnEmployeeName(id));
    }
}

नामांकित पैरामीटर सिंटैक्स का उपयोग यहां नहीं किया गया है, लेकिन चूंकि हम एक चर को पास कर रहे हैं ReturnEmployeeIds, और उस चर का एक नाम है, और यह नाम उसी चीज का मतलब होता है जिस पैरामीटर को हम इसे पारित कर रहे हैं (यह अक्सर मामला है - लेकिन हमेशा नहीं!) - हमें कोड से अर्थ समझने के लिए नामित पैरामीटर सिंटैक्स की आवश्यकता नहीं है।

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

— इदं आर्ये
स्रोत

7

मैं असहमत हूं कि ReturnEmployeeName(57)यह तुरंत स्पष्ट हो 57जाता है कि यह आईडी है। GetEmployeeById(57)दूसरी ओर ...

— ह्यूगो जिंक

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

— इदं आर्ये

1

किसी भी मामले में, यह बहुत संभावना नहीं है कि हम एक वास्तविक कार्यक्रम में ReturnEmployeeName (57) लिखेंगे। यह कहीं अधिक संभावना है कि हम ReturnEmployeeName (कर्मचारी) लिखेंगे। हम एक कर्मचारी आईडी को हार्डकोड क्यों करेंगे? जब तक यह प्रोग्रामर की आईडी नहीं है और किसी तरह की धोखाधड़ी चल रही है, जैसे, इस कर्मचारी की तनख्वाह में थोड़ा सा जोड़ें। :-)

— जय

0

हां, मुझे लगता है कि यह अच्छी शैली है।

यह बूलियन और पूर्णांक स्थिरांक के लिए सबसे अधिक समझ में आता है।

यदि आप एक चर में गुजर रहे हैं, तो चर नाम का अर्थ स्पष्ट होना चाहिए। यदि ऐसा नहीं होता है, तो आपको चर को बेहतर नाम देना चाहिए।

यदि आप एक स्ट्रिंग में गुजर रहे हैं, तो अर्थ अक्सर स्पष्ट होता है। जैसे अगर मुझे GetFooData ("ओरेगन") के लिए एक कॉल दिखाई देता है, मुझे लगता है कि एक पाठक बहुत अनुमान लगा सकता है कि पैरामीटर एक राज्य का नाम है।

सभी तार स्पष्ट नहीं हैं, निश्चित रूप से। अगर मुझे GetFooData ("M") दिखाई देता है, तो जब तक मुझे फ़ंक्शन नहीं पता है मुझे पता नहीं है कि "M" का क्या अर्थ है। यदि यह किसी प्रकार का कोड है, जैसे M = "प्रबंधन-स्तर के कर्मचारी", तो हमें संभवतः शाब्दिक के बजाय एक एनम होना चाहिए, और एनम नाम स्पष्ट होना चाहिए।

और मुझे लगता है कि एक स्ट्रिंग भ्रामक हो सकती है। हो सकता है कि ऊपर मेरे उदाहरण में "ओरेगन" संदर्भित करता है, राज्य के लिए नहीं, बल्कि उत्पाद या ग्राहक या जो भी हो।

लेकिन GetFooData (सच) या GetFooData (42) ... का मतलब कुछ भी हो सकता है। नामित पैरामीटर इसे स्व-दस्तावेजीकरण बनाने का एक शानदार तरीका है। मैंने कई मौकों पर उन्हें उस उद्देश्य के लिए इस्तेमाल किया है।

— नीलकंठ
स्रोत

0

इस प्रकार के सिंटैक्स का उपयोग पहली जगह में करने के कारण कोई सुपर स्पष्ट कारण नहीं हैं ।

सामान्य तौर पर, बूलियन तर्क रखने से बचने की कोशिश करें जो थोड़ी दूरी पर मनमानी कर सकते हैं। includeManagement(सबसे अधिक संभावना) परिणाम को बहुत प्रभावित करेगा। लेकिन तर्क ऐसा लगता है कि यह "थोड़ा वजन" वहन करता है।

एक एनम के उपयोग पर चर्चा की गई है, न केवल यह तर्क की तरह दिखेगा "अधिक वजन वहन करता है", बल्कि यह विधि को स्केलेबिलिटी भी प्रदान करेगा। हालाँकि यह सभी मामलों में सबसे अच्छा समाधान नहीं हो सकता है, क्योंकि आपके ReturnEmployeeIds-मिथोड को -enum के साथ-साथ स्केल करना होगा WhatToInclude(देखें निकलेसज का जवाब)। इससे आपको बाद में सिरदर्द हो सकता है।

इस पर विचार करें: यदि आप WhatToInclude-enum को मापते हैं, लेकिन ReturnEmployeeIds-method को नहीं । यह तब ArgumentOutOfRangeException(सर्वोत्तम मामला) फेंक सकता है या पूरी तरह से अवांछित ( nullया खाली List<Guid>) कुछ वापस कर सकता है । जो कुछ मामलों में प्रोग्रामर को भ्रमित कर सकता है, खासकर यदि आपका ReturnEmployeeIdsक्लास-लाइब्रेरी में है, जहां स्रोत-कोड आसानी से उपलब्ध नहीं है।

WhatToInclude.Traineesयदि WhatToInclude.Allकोई ऐसा करता है तो यह मान लेगा कि प्रशिक्षु सभी का "उपसमूह" है।

यह (ज़ाहिर है), कैसे ReturnEmployeeIds लागू किया जाता है पर निर्भर करता है।

उन मामलों में जहां एक बूलियन तर्क पारित किया जा सकता है, मैं आपके मामले में इसे दो तरीकों (या अधिक, यदि आवश्यक हो) में तोड़ने की कोशिश करता हूं; कोई निकाल सकता है ReturnAllEmployeeIds, ReturnManagementIdsऔर ReturnRegularEmployeeIds। यह सभी आधारों को शामिल करता है और जो कोई भी इसे लागू करता है, वह पूरी तरह से आत्म-व्याख्यात्मक होता है। यह भी "स्केलिंग" नहीं होगा, जैसा कि ऊपर उल्लेख किया गया है।

चूंकि बूलियन तर्क रखने वाली किसी चीज़ के लिए केवल दो परिणाम होते हैं । दो तरीकों को लागू करना, बहुत कम अतिरिक्त प्रयास लेता है।

कम कोड, शायद ही कभी बेहतर होता है।

साथ यह कहा, वहाँ हैं कुछ मामलों में जहां स्पष्ट रूप से तर्क की घोषणा पठनीयता में सुधार। उदाहरण के लिए विचार करें। GetLatestNews(max: 10)। GetLatestNews(10)है अभी भी बहुत आत्म व्याख्यात्मक, की स्पष्ट घोषणा maxइच्छा मदद स्पष्ट किसी भी भ्रम की स्थिति।

और अगर आपके पास पूरी तरह से एक बूलियन तर्क होना चाहिए , जिसका उपयोग सिर्फ पढ़ने से trueया अनुमान नहीं किया जा सकता है false। तब मैं कहूंगा कि:

var ids = ReturnEmployeeIds(includeManagement: true);

.. बिल्कुल बेहतर है, और इससे अधिक पठनीय है:

var ids = ReturnEmployeeIds(true);

दूसरे उदाहरण में, trueइसका मतलब बिल्कुल कुछ भी हो सकता है । लेकिन मैं इस तर्क से बचने की कोशिश करूंगा।

— मौस मरो
स्रोत