यदि ... और यदि किसी क्लॉज के साथ निर्माण होता है तो समाप्त करने का क्या लाभ है?

Question

हमारे संगठन में एक आवश्यक कोडिंग नियम है (बिना किसी स्पष्टीकरण के)

अगर ... और अगर निर्माण को किसी अन्य खंड के साथ समाप्त किया जाना चाहिए

उदाहरण 1:

if ( x < 0 )
{
   x = 0;
} /* else not needed */

उदाहरण 2:

if ( x < 0 )
{
    x = 0;
}
else if ( y < 0 )
{
    x = 3;
}
else    /* this else clause is required, even if the */
{       /* programmer expects this will never be reached */
        /* no change in value of x */
}

इसे संभालने के लिए कौन सा एज केस बनाया गया है?

मुझे इस कारण से भी चिंता है कि उदाहरण 1 की आवश्यकता नहीं है, elseलेकिन उदाहरण 2 की आवश्यकता है। यदि कारण पुन: प्रयोज्य और विस्तार है, तो मुझे लगता है कि elseदोनों मामलों में उपयोग किया जाना चाहिए।

Comments

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

— थिलो

उदाहरण 2 वास्तव में एक अच्छा उदाहरण है जहां assert(false, "should never go here")समझदारी हो सकती है

— थिलो

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

— लवजिनेसस

तुम हमेशा हार सकता है अगर साथ if (x < 0) { x = 0; } else { if (y < 0) { x = 3; }}। या आप ऐसे नियमों का पालन कर सकते हैं, जिनमें से कई मूर्ख हैं, केवल इसलिए कि आपको आवश्यक है।

— जिम बेल्टर

@ थाइलो मैं थोड़ा लेट हो गया हूं, लेकिन अभी भी किसी ने गलती नहीं पकड़ी है: ऐसा कोई संकेत नहीं है कि दूसरा कभी नहीं होना चाहिए, केवल इसका कोई साइड इफेक्ट नहीं होना चाहिए (जो < 0कि चेक करते समय सामान्य लगता है ), ताकि मुखर हो रहा हो इस कार्यक्रम को दुर्घटनाग्रस्त करने के लिए कि शायद सबसे आम मामला है जहां मूल्य अपेक्षित सीमा में हैं।

— लडुविज्क

Answer 1

जैसा कि एक अन्य जवाब में कहा गया है, यह MISRA-C कोडिंग दिशानिर्देशों से है। उद्देश्य रक्षात्मक प्रोग्रामिंग है, एक अवधारणा जो अक्सर मिशन-महत्वपूर्ण प्रोग्रामिंग में उपयोग की जाती है।

यही है, हर if - else ifएक के साथ समाप्त होना चाहिए else, और हर switchएक के साथ समाप्त होना चाहिए default।

इसके लिए दो कारण हैं:

• स्व-दस्तावेज कोड। यदि आप लिखते हैं, elseलेकिन इसे खाली छोड़ देते हैं तो इसका मतलब है: "मैंने निश्चित रूप से परिदृश्य पर विचार किया है जब न तो सच है ifऔर न ही else if"।

  elseवहां लिखने का मतलब नहीं है: "या तो मैंने उस परिदृश्य पर विचार किया, जहां न तो सच है ifऔर न ही else ifमैं इस पर विचार करना पूरी तरह से भूल गया हूं और संभवतः मेरे कोड में यहीं एक वसा बग है"।

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

  if (mybool == TRUE) 
  {
  } 
  else if (mybool == FALSE) 
  {
  }
  else
  {
    // handle error
  }

  यह कोड पीसी प्रोग्रामर और कंप्यूटर वैज्ञानिकों के लिए पूरी तरह से विदेशी होगा, लेकिन यह मिशन-क्रिटिकल सॉफ़्टवेयर में सही अर्थों में बनाता है, क्योंकि यह उस मामले को पकड़ता है जहां "मायबूल" भ्रष्ट हो गया है, जो भी कारण से।

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

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

---

संपादित करें

elseहर एक के बाद की जरूरत क्यों नहीं है के बारे मेंif :

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

साथ ही यह कोड को पूरी तरह से बंद कर देगा यदि आप elseप्रत्येक और प्रत्येक के बाद एक खाली लिखा है if।

MISRA-C: 2012 15.7 कोई तर्क नहीं देता है कि elseइसकी आवश्यकता क्यों नहीं है, यह सिर्फ बताता है:

नोट: एक elseसाधारण if कथन के लिए अंतिम कथन की आवश्यकता नहीं है ।

Comments

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

— ओलेग वी। वोल्कोव

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

— लंडिन

@ डेडप्लिकेटर वास्तव में (जब तक myboolकि एक गैर-बूलियन प्रकार नहीं होता है, जैसा कि सी के अपने होने से पहले ही मामला वापस आ गया था bool; तब कंपाइलर अतिरिक्त स्थैतिक विश्लेषण के बिना धारणा नहीं बनाएगा)। और 'यदि आप एक और लिखते हैं, लेकिन इसे खाली छोड़ देते हैं, तो इसका मतलब है: "मैंने निश्चित रूप से इस परिदृश्य पर विचार किया है जब न तो और न ही अगर यह सच है"। ": मेरी पहली प्रतिक्रिया यह मान लेना है कि प्रोग्रामर कोड डालना भूल गया। दूसरा ब्लॉक, अन्यथा खाली ब्लॉक क्यों बैठे हैं? एक // unusedटिप्पणी उचित होगी, न कि केवल एक खाली ब्लॉक।

— JAB

@JAB हां, कोड नहीं होने पर elseब्लॉक को किसी प्रकार की टिप्पणी करने की आवश्यकता है। खाली के लिए सामान्य अभ्यास elseएक एकल अर्धविराम प्लस एक टिप्पणी है else { ; // doesn't matter }:। जैसा कि कोई कारण नहीं है कि कोई भी अन्यथा केवल एक लाइन पर एक इंडेंटेड, सिंगल सेमी कोलोन टाइप करेगा। इसी तरह के अभ्यास को कभी-कभी खाली छोरों में उपयोग किया जाता है while(something) { ; // do nothing }:। (लाइन ब्रेक के साथ कोड, स्पष्ट रूप से। एसओ टिप्पणियां उन्हें अनुमति नहीं देती हैं)

— लुंडिन

मैं यह नोट करना चाहूंगा, कि दो आईएफएस के साथ यह नमूना कोड और भी बहु-थ्रेडेड वातावरण में सामान्य डेस्कटॉप सॉफ़्टवेयर में और भी जा सकता है, इसलिए mybool का मूल्य केवल बीच में बदला जा सकता है

— Iłya Bursov

Answer 2

आपकी कंपनी ने MISRA कोडिंग मार्गदर्शन का पालन किया। इन दिशानिर्देशों कि इस नियम को शामिल करने के कुछ संस्करण हैं, लेकिन से मिश्रा सी: 2004 ^† :

नियम १४.१० (आवश्यक): यदि सभी निर्माण एक और खंड के साथ समाप्त किए जाएंगे।

यह नियम तब लागू होता है जब कोई बयान एक या एक से अधिक कथन के बाद होता है; अंतिम विवरण के ifबाद अंतिम elseविवरण दिया जाएगा। एक साधारण ifबयान के मामले में तो else बयान को शामिल करने की आवश्यकता नहीं है। एक अंतिम else बयान के लिए आवश्यकता रक्षात्मक प्रोग्रामिंग है। elseबयान या तो उचित कार्रवाई करने के या क्यों कोई कार्रवाई नहीं की है के रूप में एक उपयुक्त टिप्पणी शामिल होगा। यह defaultएक switchबयान में अंतिम खंड होने की आवश्यकता के अनुरूप है । उदाहरण के लिए यह कोड एक सरल है यदि कथन:

if ( x < 0 )
{
 log_error(3);
 x = 0;
} /* else not needed */

जबकि निम्नलिखित कोड एक if, else ifनिर्माण को प्रदर्शित करता है

if ( x < 0 )
{
 log_error(3);
 x = 0;
}
else if ( y < 0 )
{
 x = 3;
}
else /* this else clause is required, even if the */
{ /* programmer expects this will never be reached */
 /* no change in value of x */
}

में मिश्रा सी: 2012 , जो 2004 संस्करण का स्थान लेता है और नई परियोजनाओं के लिए वर्तमान सिफारिश है, यही नियम मौजूद है, लेकिन 15.7 गिने है ।

उदाहरण 1: एकल में यदि स्टेटमेंट प्रोग्रामर को n की संख्या की जाँच करने और एकल ऑपरेशन करने की आवश्यकता हो सकती है।

if(condition_1 || condition_2 || ... condition_n)
{
   //operation_1
}

एक नियमित उपयोग में ऑपरेशन करते समय हर समय ifउपयोग किए जाने की आवश्यकता नहीं होती है।

उदाहरण 2: यहाँ प्रोग्रामर कई स्थितियों की जाँच करता है और कई ऑपरेशन करता है। नियमित रूप से उपयोग में if..else ifहै जैसे कि switchआपको डिफ़ॉल्ट जैसे ऑपरेशन करने की आवश्यकता हो सकती है। इसलिए elseमिश्रा मानक के अनुसार उपयोग की आवश्यकता है

if(condition_1 || condition_2 || ... condition_n)
{
   //operation_1
}
else if(condition_1 || condition_2 || ... condition_n)
{
  //operation_2
}
....
else
{
   //default cause
}

---

^Ations इन प्रकाशनों के वर्तमान और पिछले संस्करण MISRA वेबस्टोर ( थ्रू ) के माध्यम से खरीदने के लिए उपलब्ध हैं ।

Comments

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

— ट्रेवर

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

— jpmc26

मैं साहित्यिक चोरी और कॉपीराइट का उल्लंघन करने वाले लिंक के लिए वोट डाउन करने जा रहा हूं। मैं पोस्ट को संपादित करूँगा ताकि यह स्पष्ट हो जाए कि आपके शब्द क्या हैं और MISRA के शब्द क्या हैं। शुरू में यह जवाब एक कच्ची कॉपी / पेस्ट के अलावा कुछ नहीं था।

— लुंडिन

@TrieuTheVan: प्रश्न लक्ष्य नहीं होने चाहिए । सुनिश्चित करें कि आपका प्रश्न पोस्ट करने से पहले पूरा हो गया है।

— टीजे क्राउडर

@ jpmc26 नहीं, लेकिन MISRA की बात आपको तंग कोड देने की नहीं है, यह आपको सुरक्षित कोड देने के लिए है। इन दिनों कोई भी कंपाइलर वैसे भी अगम्य कोड का अनुकूलन करेगा, इसलिए इसका कोई नकारात्मक पहलू नहीं है।

— ग्राहम

Answer 3

यह हर स्विच में एक डिफ़ॉल्ट मामले की आवश्यकता के बराबर है।

यह अतिरिक्त आपके प्रोग्राम का कोड कवरेज घटा देगा ।

---

लाइनिंग कर्नेल, या एंड्रॉइड कोड को अलग-अलग प्लेटफ़ॉर्म पर पोर्ट करने के मेरे अनुभव में कई बार हम कुछ गलत करते हैं और लॉगकोट में हम कुछ गलतियाँ करते हैं जैसे

if ( x < 0 )
{
    x = 0;
}
else if ( y < 0 )
{
    x = 3;
}
else    /* this else clause is required, even if the */
{       /* programmer expects this will never be reached */
        /* no change in value of x */
        printk(" \n [function or module name]: this should never happen \n");

        /* It is always good to mention function/module name with the 
           logs. If you end up with "this should never happen" message
           and the same message is used in many places in the software
           it will be hard to track/debug.
        */
}

Comments

यह वह जगह है जहां __FILE__और __LINE__मैक्रो यदि संदेश कभी छपा है आसानी से मिल स्रोत स्थान बनाने के लिए एक उपयोगी होते हैं।

— पीटर कॉर्ड्स

Answer 4

केवल एक संक्षिप्त विवरण, क्योंकि मैंने यह सब लगभग 5 साल पहले किया था।

वहाँ (अधिकांश भाषाओं के साथ) "शून्य" elseबयान (और अनावश्यक ) को शामिल करने के लिए कोई वाक्यात्मक आवश्यकता नहीं है{..} ) , और "सरल छोटे कार्यक्रमों" में कोई आवश्यकता नहीं है। लेकिन असली प्रोग्रामर "सरल छोटे प्रोग्राम" नहीं लिखते हैं, और, महत्वपूर्ण रूप से, वे ऐसे प्रोग्राम नहीं लिखते हैं जिन्हें एक बार उपयोग किया जाएगा और फिर छोड़ दिया जाएगा।

जब कोई लिखता है यदि

if(something)
  doSomething;
else
  doSomethingElse;

यह सब सरल लगता है और एक को जोड़ने का बिंदु भी मुश्किल से दिखता है {..}।

लेकिन किसी दिन, अब से कुछ महीने बाद, कुछ अन्य प्रोग्रामर (आप ऐसी गलती कभी नहीं करेंगे!) को कार्यक्रम को "बढ़ाने" और एक बयान जोड़ने की आवश्यकता होगी।

if(something)
  doSomething;
else
  doSomethingIForgot;
  doSomethingElse;

अचानक doSomethingElseथोड़े भूल जाते हैं कि यह elseपैर में होना चाहिए ।

तो आप एक अच्छे छोटे प्रोग्रामर हैं और आप हमेशा उपयोग करते हैं {..}। लेकिन आप लिखते हैं:

if(something) {
  if(anotherThing) {
    doSomething;
  }
}

जब तक कि नया बच्चा आधी रात में संशोधन नहीं कर लेता, तब तक सब ठीक और अच्छा है:

if(something) {
  if(!notMyThing) {
  if(anotherThing) {
    doSomething;
  }
  else {
    dontDoAnything;  // Because it's not my thing.
  }}
}

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

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

Answer 5

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

यह एक अच्छा प्रोग्रामिंग अभ्यास है, जो कोड को पुन: प्रयोज्य और विस्तारित-सक्षम बनाता है ।

Answer 6

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

सवाल ही एक अच्छा प्रति-उदाहरण पेश करता है: दूसरी स्थिति x से बिल्कुल भी संबंधित नहीं है (यही कारण है कि मैं अक्सर स्विच-आधारित संस्करण के आधार पर अधिक लचीला if- आधारित संस्करण पसंद करता हूं)। उदाहरण से यह स्पष्ट है कि यदि A से मुलाकात की जाती है, तो x को एक निश्चित मान पर सेट किया जाना चाहिए। क्या A से मुलाकात नहीं की जानी चाहिए, तो B की स्थिति का परीक्षण किया जाएगा। यदि यह मिलता है, तो x को एक और मान प्राप्त करना चाहिए। यदि न तो A और न ही B मिलते हैं, तो x अपरिवर्तित रहना चाहिए।

यहां हम देख सकते हैं कि पाठक के लिए प्रोग्रामर के इरादे पर टिप्पणी करने के लिए एक खाली शाखा का उपयोग किया जाना चाहिए।

दूसरी ओर, मैं यह नहीं देख सकता कि बयान के लिए विशेष रूप से नवीनतम और अंतरतम के लिए एक और खंड क्यों होना चाहिए। C में, 'if if' जैसी कोई चीज नहीं है। अगर और है तो ही है। इसके बजाय, MISRA के अनुसार, निर्माण को औपचारिक रूप से इस तरह से इंडेंट किया जाना चाहिए (और मुझे अपनी लाइनों पर शुरुआती घुंघराले ब्रेसिज़ लगाने चाहिए, लेकिन मुझे यह पसंद नहीं है):

if (A) {
    // do something
}
else {
    if (B) {
        // do something else (no pun intended)
    }
    else {
        // don't do anything here
    }
}

जब MISRA हर शाखा के चारों ओर घुंघराले ब्रेसिज़ लगाने के लिए कहता है, तो यह "यदि ... और यदि निर्माण करता है" का उल्लेख करके खुद को विरोधाभासी करता है।

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

if (A) {
    if (B) {
        // do something
    }
    // you could to something here
}
else {
    // or here
    if (B) { // or C?
        // do something else (no pun intended)
    }
    else {
        // don't do anything here, if you don't want to
    }
    // what if I wanted to do something here? I need brackets for that.
}

इसलिए मुझे यकीन है कि जिन लोगों ने MISRA दिशा-निर्देश विकसित किए हैं, उनके पास स्विच-जैसे if- और अगर इरादे हैं।

अंत में, यह उनके लिए ठीक-ठीक परिभाषित करने के लिए आता है कि "अगर ... और यदि निर्माण करें"

Answer 7

मूल कारण शायद कोड कवरेज और निहितार्थ है: यदि हालत सही नहीं है तो कोड कैसे व्यवहार करेगा? वास्तविक परीक्षण के लिए, आपको यह देखने के लिए कुछ तरीके की आवश्यकता है कि आपने झूठी स्थिति के साथ परीक्षण किया है। यदि आपके द्वारा लिए गए प्रत्येक परीक्षण का मामला यदि क्लॉज से गुजरता है, तो आपके कोड को वास्तविक स्थिति में समस्या हो सकती है क्योंकि आपने परीक्षण नहीं किया था।

हालांकि, कुछ शर्तें ठीक से उदाहरण 1 की तरह हो सकती हैं, जैसे कर रिटर्न पर: "यदि परिणाम 0 से कम है, तो 0. दर्ज करें।" आपको अभी भी एक परीक्षण करने की आवश्यकता है जहां स्थिति झूठी है।

Answer 8

तार्किक रूप से किसी भी परीक्षा का तात्पर्य दो शाखाओं से है। अगर यह सच है, तो आप क्या करते हैं और अगर यह गलत है तो आप क्या करते हैं।

उन मामलों के लिए जहां या तो शाखा में कोई कार्यक्षमता नहीं है, यह टिप्पणी करना उचित है कि इसके लिए कार्यक्षमता की आवश्यकता क्यों नहीं है।

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

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

आपकी माइलेज भिन्न हो सकती है।

Answer 9

ज्यादातर समय जब आप सिर्फ एक ifबयान देते हैं, तो यह संभवतः एक कारण है जैसे:

• फंक्शन गार्ड की जाँच
• प्रारंभिक विकल्प
• वैकल्पिक प्रसंस्करण शाखा

उदाहरण

void print (char * text)
{
    if (text == null) return; // guard check

    printf(text);
}

लेकिन जब आप ऐसा करते हैं if .. else if, तो शायद यह एक कारण है:

• गतिशील स्विच-केस
• प्रसंस्करण कांटा
• एक प्रसंस्करण पैरामीटर को संभालना

और यदि आपकी if .. else ifसभी संभावनाओं को कवर किया जाता है, उस स्थिति में आपके अंतिम if (...)की आवश्यकता नहीं है, तो आप इसे हटा सकते हैं, क्योंकि उस समय एकमात्र संभावित मान उस स्थिति से आच्छादित होते हैं।

उदाहरण

int absolute_value (int n)
{
    if (n == 0)
    {
        return 0;
    }
    else if (n > 0)
    {
        return n;
    }
    else /* if (n < 0) */ // redundant check
    {
        return (n * (-1));
    }
}

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

उदाहरण

#DEFINE SQRT_TWO   1.41421356237309504880
#DEFINE SQRT_THREE 1.73205080756887729352
#DEFINE SQRT_FIVE  2.23606797749978969641

double square_root (int n)
{
         if (n  > 5)   return sqrt((double)n);
    else if (n == 5)   return SQRT_FIVE;
    else if (n == 4)   return 2.0;
    else if (n == 3)   return SQRT_THREE;
    else if (n == 2)   return SQRT_TWO;
    else if (n == 1)   return 1.0;
    else if (n == 0)   return 0.0;
    else               return sqrt(-1); // error handling
}

इस अंतिम elseखंड काफी जैसे भाषाओं में कुछ अन्य बातें करने के लिए इसी तरह की है Javaऔर C++इस तरह के रूप,:

• default एक स्विच स्टेटमेंट में मामला
• catch(...)यह सभी विशिष्ट catchब्लॉकों के बाद आता है
• finally एक कोशिश में पकड़ खंड

Answer 10

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

Answer 11

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

int a = 0;
bool b = true;
uint8_t* bPtr = (uint8_t*)&b;
*bPtr = 0xCC;
if(b == true)
{
    a += 3;
}
else if(b == false)
{
    a += 5;
}
else
{
    exit(3);
}

आप शायद पड़ सकती है कभी नहीं होगा boolजो नहीं है trueऔर न ही false, लेकिन यह हो सकता है। व्यक्तिगत रूप से मेरा मानना ​​है कि यह उस व्यक्ति के कारण होने वाली समस्या है जो कुछ फैंसी करने का फैसला करता है, लेकिन अतिरिक्त elseबयान किसी भी अन्य मुद्दों को रोक सकता है।

Answer 12

मैं वर्तमान में PHP के साथ काम कर रहा हूँ। एक पंजीकरण फॉर्म और एक लॉगिन फॉर्म बनाना। मैं सिर्फ विशुद्ध रूप से अगर और का उपयोग कर रहा हूँ। कोई और नहीं तो कुछ भी जो अनावश्यक है।

यदि उपयोगकर्ता बटन क्लिक करता है -> यह अगले स्टेटमेंट पर जाता है ... यदि उपयोगकर्ता नाम 'X' अक्षर से कम है तो अलर्ट करें। यदि सफल है तो पासवर्ड की लंबाई आदि की जांच करें।

अतिरिक्त कोड की कोई आवश्यकता नहीं है जैसे कि यदि सभी अतिरिक्त कोड की जांच करने के लिए सर्वर लोड समय के लिए विश्वसनीयता को खारिज कर सकता है।