अगर / वापसी पर सबसे अच्छा अभ्यास

Question

मैं जानना चाहता हूं कि जब मेरे पास ifबयान हो तो वापसी का बेहतर तरीका क्या है ।

उदाहरण 1:

public bool MyFunction()
{
   // Get some string for this example
   string myString = GetString();

   if (myString == null)
   {
      return false;
   }
   else
   {
      myString = "Name " + myString;
      // Do something more here...
      return true;
   }
}

उदाहरण 2:

public bool MyFunction()
{
   // Get some string for this example
   string myString = GetString();

   if (myString == null)
   {
      return false;
   }

   myString = "Name " + myString;
   // Do something more here...
   return true;
}

जैसा कि आप दोनों उदाहरणों में देख सकते हैं कि फ़ंक्शन वापस आ जाएगा true/falseलेकिन क्या elseपहले उदाहरण की तरह बयान डालना अच्छा है या इसे नहीं डालना बेहतर है?

Comments

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

— मर्ट अक्काया

व्यक्तिगत रूप से मैं समारोह के दुष्प्रभाव के बारे में अधिक चिंतित हूं, लेकिन मुझे लगता है कि यह सिर्फ एक खराब चुना हुआ उदाहरण है?

— जे.के.

संबंधित: क्यों "और" शायद ही कभी इस्तेमाल किया जाता है के बाद "अगर x तो वापस"?

— मोनिका

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

— निकोल

'यहाँ कुछ और करो ’जो आप करना चाहते हैं? यह पूरी तरह से बदल सकता है कि आप अपने फ़ंक्शन को कैसे डिज़ाइन करते हैं।

— बेनेडिक्ट

Answer 1

उदाहरण 2 को गार्ड ब्लॉक के रूप में जाना जाता है। यदि कुछ गलत हुआ (गलत पैरामीटर या अमान्य स्थिति) तो अपवाद को जल्दी वापस करना / फेंकना बेहतर है। सामान्य तर्क प्रवाह में उदाहरण 1 का उपयोग करना बेहतर होता है

Comments

+1 - एक अच्छा अंतर, और मैं क्या जवाब देने वाला था।

— तेलस्टीन जूल

@ pR0Ps का नीचे एक ही जवाब है और एक कोड उदाहरण प्रदान करता है कि क्यों यह एक क्लीनर पथ का अनुसरण करने के लिए समाप्त होता है। अच्छे उत्तर के लिए +1।

यह सवाल एसओ पर कई बार पूछा गया है और हालांकि यह विवादास्पद हो सकता है यह एक अच्छा जवाब है। बहुत से लोग जिन्हें केवल अंत से लौटने के लिए प्रशिक्षित किया गया था, इस अवधारणा के साथ कुछ समस्याएं हैं।

— बिल के

+1। अनुचित रूप से गार्ड ब्लॉक से बचने के लिए तीर कोड का कारण बनता है।

— ब्रायन

दोनों उदाहरण गार्ड ब्लॉक नहीं दिखाते हैं?

— ernie

Answer 2

मेरी व्यक्तिगत शैली ifगार्ड ब्लॉकों के लिए एकल का उपयोग करना है , और if/ elseवास्तविक विधि प्रसंस्करण कोड में।

इस स्थिति में, आप myString == nullएक गार्ड की स्थिति के रूप में उपयोग कर रहे हैं, इसलिए मैं एकल ifपैटर्न का उपयोग करना चाहूंगा ।

उस कोड पर विचार करें जो थोड़ा अधिक जटिल है:

उदाहरण 1:

public bool MyFunction(myString: string){

    //guard block
    if (myString == null){
        return false;
    }
    else{
        //processing block
        myString = escapedString(myString);

        if (myString == "foo"){
            //some processing here
            return false;
        }
        else{
            myString = "Name " + myString;
            //other stuff
            return true;
        }
    }
}

उदाहरण 2:

public bool MyFunction(myString: string){

    //guard block
    if (myString == null){
        return false;
    }

    //processing block
    myString = escapedString(myString);

    if (myString == "foo"){
        //some processing here
        return false;
    }
    else{
        myString = "Name " + myString;
        //other stuff
        return true;
    }
}

उदाहरण 1 में, दोनों गार्ड और बाकी विधि if/ elseफॉर्म में हैं। इसकी तुलना उदाहरण 2 से करें, जहां गार्ड ब्लॉक एकल ifरूप में है, जबकि बाकी विधि if/ elseफॉर्म का उपयोग करती है। व्यक्तिगत रूप से, मुझे उदाहरण 2 समझने में आसान लगता है, जबकि उदाहरण 1 गन्दा और अधिक इंडेंट दिखता है।

ध्यान दें कि यह एक विवादित उदाहरण है और आप else ifइसे साफ करने के लिए बयानों का उपयोग कर सकते हैं , लेकिन मैं लक्ष्य रख रहा हूं कि गार्ड ब्लॉक और वास्तविक फ़ंक्शन प्रोसेसिंग कोड के बीच का अंतर दिखाएं।

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

Comments

उदाहरण 2 पढ़ने के लिए और भी आसान होगा यदि आप दूसरे से छुटकारा पा लें।

— :

Answer 3

व्यक्तिगत रूप से, मैं दूसरी विधि पसंद करता हूं। मुझे लगता है जैसे यह छोटा है, कम इंडेंटेशन है, और पढ़ने में आसान है।

Comments

कम इंडेंटेशन के लिए +1। यदि आपके पास कई जांचें हैं, तो यह इशारा बहुत ही आसान है

— d.raev

Answer 4

मेरा व्यक्तिगत अभ्यास निम्नलिखित है:

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

उदाहरण के लिए:

public bool myFunction()
{
   // First parameter loading
   String myString = getString();

   // Location of "quick exits", see the second example
   // ...

   // declaration of external resources that MUST be released whatever happens
   // ...

   // the return variable (should think about giving it a default value or not) 
   // if you have no default value, declare it final! You will get compiler 
   // error when you try to set it multiple times or leave uninitialized!
   bool didSomething = false;

   try {
     if (myString != null)
     {
       myString = "Name " + myString;
       // Do something more here...

       didSomething = true;
     } else {
       // get other parameters and data
       if ( other conditions apply ) {
         // do something else
         didSomething = true;
       }
     }

     // Edit: previously forgot the most important advantage of this version
     // *** HOUSEKEEPING!!! ***

   } finally {

     // this is the common place to release all resources, reset all state variables

     // Yes, if you use try-finally, you will get here from any internal returns too.
     // As I said, it is only my taste that I like to have one, straightforward path 
     // leading here, and this works even if you don't use the try-finally version.

   }

   return didSomething;
}

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

उदाहरण के लिए:

public bool myFunction()
{
   String myString = getString();

   if (null == myString)
   {
     // there is nothing to do if myString is null
     return false;
   } 

   myString = "Name " + myString;
   // Do something more here...

   // not using return value variable now, because the operation is straightforward.
   // if the operation is complex, use the variable as the previous example.

   return true;
}

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

आपका मामला "वास्तविक कार्य से पहले त्वरित निकास" श्रेणी में आता है, और मैं इसे आपके उदाहरण 2 संस्करण की तरह लिखूंगा।

Comments

+1 के लिए "मुझे कई एक्ज़िट पॉइंट्स वाले फ़ंक्शंस पसंद नहीं हैं"

— Corv1nus

@LorandKedves - ने एक उदाहरण जोड़ा - आशा है कि आपको कोई आपत्ति नहीं है।

— मैथ्यू फ्लिन

@MatthewFlynn अच्छी तरह से, यदि आप कोई आपत्ति नहीं है कि यह मैं क्या मेरा उत्तर ;-) मैं उदाहरण जारी के अंत में सुझाव के विपरीत है, मैं अंत में आशा है कि यह हम दोनों के लिए अच्छा होगा :-)

— Lorand Kedves

@MatthewFlynn (क्षमा करें, मैं सिर्फ एक केकड़ा कमीने हूं, और मेरी राय को स्पष्ट करने में मेरी मदद करने के लिए धन्यवाद। मुझे उम्मीद है कि आप मौजूदा संस्करण को पसंद करेंगे।)

— लोरैंड केड्स

कई एक्ज़िट पॉइंट्स के साथ फ़ंक्शंस और एक म्यूटेबल रिजल्ट वेरिएबल वाले फ़ंक्शंस में, पूर्व मुझे दो बुराइयों से कम लगता है।

— जॉन प्यूडी

Answer 5

मैं दो कारणों से कभी भी जहाँ मैं कर सकता हूँ गार्ड ब्लॉक को रोजगार देना पसंद करता हूँ:

1. वे कुछ विशिष्ट स्थिति को देखते हुए एक त्वरित निकास की अनुमति देते हैं।
2. यदि कोड में बाद में बयान किए गए हैं तो जटिल और गैर-आवश्यक के लिए आवश्यकता को हटा दें।

आम तौर पर बोलना मैं उन तरीकों को देखना पसंद करता हूं जहां विधि की मुख्य कार्यक्षमता स्पष्ट और न्यूनतम है। गार्ड ब्लॉक नेत्रहीन को ऐसा करने में मदद करते हैं।

Answer 6

मुझे "पतन थ्रू" दृष्टिकोण पसंद है:

public bool MyFunction()
{
   string myString = GetString();

   if (myString != null)
   {
     myString = "Name " + myString;
     return true;
    }
    return false;
}

कार्रवाई की एक विशिष्ट स्थिति है, और कुछ भी बस "वापसी के माध्यम से डिफ़ॉल्ट" है।

Answer 7

अगर मैं एक भी अगर मैं हालत मैं शैली के बारे में ruminating बहुत अधिक समय खर्च नहीं होगा। लेकिन अगर मेरे पास कई गार्ड स्थितियां हैं, तो मैं स्टाइल 2 को पसंद करूंगा

इसको पिचके। मान लें कि परीक्षण जटिल हैं और आप वास्तव में जटिलता से बचने के लिए उन्हें एक एकल-ओरेड स्थिति में बाँधना नहीं चाहते हैं:

//Style1
if (this1 != Right)
{ 
    return;
}
else if(this2 != right2)
{
    return;
}
else if(this3 != right2)
{
    return;
}
else
{
    //everything is right
    //do something
    return;
}

बनाम

//Style 2
if (this1 != Right)
{ 
   return;
}
if(this2 != right2)
{
    return;
}
if(this3 != right2)
{
    return;
}


//everything is right
//do something
return;

यहाँ दो मुख्य फायदे हैं

1. आप किसी एकल फ़ंक्शन में कोड को दो नेत्रहीन लॉग ब्लॉक में अलग कर रहे हैं: सत्यापन का ऊपरी ब्लॉक (गार्ड की स्थिति) और रन करने योग्य कोड का निचला ब्लॉक।

2. यदि आपको एक शर्त को जोड़ना / हटाना है, तो आप पूरी तरह से अगर-और-और सीढ़ी को गड़बड़ाने के अपने अवसरों को कम करते हैं।

एक और मामूली फायदा यह है कि आपके पास देखभाल करने के लिए ब्रेसिज़ का एक कम सेट है।

Answer 8

यह एक ऐसा मामला होना चाहिए, जो बेहतर लगे।

If condition
  do something
else
  do somethingelse

खुद को बेहतर तब व्यक्त करता है

if condition
  do something
do somethingelse

छोटे तरीकों के लिए यह बहुत अंतर नहीं होगा, लेकिन बड़े यौगिक तरीकों के लिए इसे समझना कठिन हो सकता है क्योंकि यह अलग नहीं होगा

Comments

यदि कोई विधि इतनी लंबी है कि दूसरा रूप समझना कठिन है, तो यह बहुत लंबा है।

— केविन क्लाइन

यदि आपके do somethingरिटर्न में आपके दो मामले समतुल्य हैं। यदि नहीं, तो दूसरा कोड विधेय do somethingelseकी परवाह किए बिना निष्पादित करेगा ifजो यह नहीं है कि पहला ब्लॉक कैसे काम करता है।

— अदनान

वे भी वही हैं जो ओपी अपने उदाहरणों में समझा रहे थे। प्रश्न की पंक्ति के ठीक बाद

— जोस वैलेंटे

Answer 9

मुझे उदाहरण 1 परेशान लगता है, क्योंकि मूल्य-वापसी फ़ंक्शन के अंत में लापता रिटर्न स्टेटमेंट तुरंत "प्रतीक्षा करें, कुछ गड़बड़ है" -flag। तो इस तरह के मामलों में, मैं उदाहरण 2 के साथ जाऊंगा।

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

Answer 10

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

Answer 11

आपके उदाहरण में, elseस्पष्ट रूप से अनावश्यक है, लेकिन ...

कोड की रेखाओं के माध्यम से तेज़ी से स्किमिंग करते समय, किसी की आँखें आमतौर पर कोड के प्रवाह का अंदाजा लगाने के लिए ब्रेसिज़ और इंडेंटेशन को देखती हैं; इससे पहले कि वे वास्तव में कोड पर ही समझौता करते हैं। इसलिए, कोड लिखना elseऔर कोड के दूसरे ब्लॉक के चारों ओर ब्रेसिज़ और इंडेंटेशन डालना वास्तव में पाठक को यह देखने के लिए तेज बनाता है कि यह "ए या बी" स्थिति है, जहां एक ब्लॉक या दूसरा चलेगा। यही है, पाठक ब्रेसिज़ और इंडेंटेशन को देखता है, क्योंकि वे returnप्रारंभिक के बाद देखते हैं if।

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

Answer 12

मैं उदाहरण 2 को पसंद करूंगा क्योंकि यह तुरंत स्पष्ट है कि फ़ंक्शन कुछ देता है । लेकिन इससे भी अधिक, मैं इस तरह से एक जगह से लौटना पसंद करूंगा:

public bool MyFunction()
{
    bool result = false;

    string myString = GetString();

    if (myString != nil) {
        myString = "Name " + myString;

        result = true;
    }

    return result;
}

इस शैली के साथ मैं कर सकता हूँ:

1. तुरंत देखिए कि मैं कुछ वापस कर रहा हूं।

2. केवल एक ब्रेकपॉइंट के साथ फ़ंक्शन के प्रत्येक आह्वान के परिणाम को पकड़ो।

Comments

यह इस तरह है कि मैं इस समस्या को कैसे समझूंगा। एकमात्र अंतर यह है कि मैं myString मूल्यांकन को पकड़ने के लिए परिणाम चर का उपयोग करूंगा और इसे वापसी मूल्य के रूप में उपयोग करूंगा।

— चक Conway

@ChuckConway सहमत है, लेकिन मैं ओपी के प्रोटोटाइप से चिपके रहने की कोशिश कर रहा था।

— कालेब

Answer 13

मेरी व्यक्तिगत शैली को जाना जाता है

function doQuery(string) {
    if (!query(string)) {
        query("ABORT");
        return false;
    } // else
    if(!anotherquery(string) {
        query("ABORT");
        return false;
    } // else
    return true;
}

elseकार्यक्रम के प्रवाह को इंगित करने और इसे पढ़ने योग्य बनाए रखने के लिए टिप्पणी-किए गए कथनों का उपयोग करना , लेकिन बड़े पैमाने पर संकेत से बचना जो बहुत सारे चरणों में शामिल होने पर आसानी से स्क्रीन पर पहुंच सकते हैं।

Comments

व्यक्तिगत रूप से, मुझे आशा है कि मुझे कभी भी आपके कोड के साथ काम नहीं करना पड़ेगा।

— एक CVn

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

— चक कॉनवे

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

— मार्क हर्ड

Answer 14

मैं लिखूंगा

public bool SetUserId(int id)
{
   // Get user name from id
   string userName = GetNameById(id);

   if (userName != null)
   {
       // update local ID and userName
       _id = id;
       _userNameLabelText = "Name: " + userName;
   }

   return userName != null;
}

मैं इस शैली को पसंद करता हूं क्योंकि यह सबसे स्पष्ट है कि मैं लौटूंगा userName != null।

Comments

सवाल यह है कि आप उस शैली को क्यों पसंद करते हैं?

— कालेब

... सच कहूँ, मुझे यकीन नहीं है कि आप इस मामले में भी स्ट्रिंग क्यों चाहते हैं, यह उल्लेख करने के लिए नहीं कि आप अंत में एक अतिरिक्त बूलियन परीक्षण क्यों जोड़ रहे हैं जो आपको वास्तव में किसी भी कारण से ज़रूरत नहीं है।

— शादुर

@ बहादुर मैं अतिरिक्त बूलियन परीक्षण और अप्रयुक्त myStringपरिणाम से अवगत हूं । मैं सिर्फ ओपी के फंक्शन को कॉपी करता हूं। मैं इसे ऐसी चीज़ में बदल दूंगा, जो वास्तविक जीवन में अधिक दिखती है। बूलियन परीक्षण तुच्छ है और इसे जारी नहीं किया जाना चाहिए।

— टिया

@ बहादुर हम यहाँ अनुकूलन नहीं कर रहे हैं, है ना? मेरी बात यह है कि मेरे कोड को पढ़ना और बनाए रखना आसान है, और व्यक्तिगत रूप से मैं एक संदर्भ शून्य चेक की लागत के साथ भुगतान करूंगा।

— टिया

@tia मुझे आपके कोड की आत्मा पसंद है। दो बार उपयोगकर्ता नाम का मूल्यांकन करने के बजाय, मैं पहले मूल्यांकन को एक चर में कैप्चर करूंगा और उसे वापस करूंगा।

— चक कॉनवे

Answer 15

अंगूठे का मेरा नियम है कि या तो बिना किसी रिटर्न के (अधिकतर त्रुटियों के लिए) या सभी संभावनाओं के लिए एक पूर्ण इफ-इफ-चेन किया जाए।

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

आपके मामले में, उदाहरण के लिए, मैं एक सादे का उपयोग करूँगा, अगर "वापसी अगर अशक्त" एक सामान्य पैटर्न है और इसकी संभावना नहीं है कि आपको तीसरी संभावना के बारे में चिंता करने की आवश्यकता होगी (अशक्त / शून्य के अलावा) भविष्य में।

हालाँकि, यदि परीक्षण कुछ ऐसा था जो डेटा पर अधिक गहन निरीक्षण करता था तो मैं इसके बजाय पूर्ण-अन्य की ओर गलत करूंगा।

Answer 16

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

क्या होगा अगर बाद में कोड को अनजाने में 2 उदाहरण के लिए पेश किया गया था जो ouput को काफी बदल दिया था:

   if (myString == null)
   {
      return false;
   }

   //add some v1 update code here...
   myString = "And the winner is: ";
   //add some v2 update code here...
   //buried in v2 updates the following line was added
   myString = null;
   //add some v3 update code here...
   //Well technically this should not be hit because myString = null
   //but we already passed that logic
   myString = "Name " + myString;
   // Do something more here...
   return true;

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

मैं इस पर अपना कुछ विश्वास कोडप्लेक्स के C # दिशानिर्देशों (यहाँ तक कि लिंक: http://csharpguidelines.codeplex.com/ ) पर कुछ हद तक देता हूँ :

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

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

Comments

उदाहरण दो में एक और नहीं होने से सभी मामलों को कैसे ध्यान में रखा जाता है? इच्छित परिणाम आईएस ने जारी रखा। इस मामले में एक और क्लॉज जोड़ने से केवल विधि की जटिलता बढ़ जाती है।

— चक कॉनवे

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

— 20