ब्लॉक

Question

ब्लॉक के साथ स्विच/केस स्टेटमेंट में ब्रेक डालने के लिए, जब मैं चर के स्थानीयकरण के लिएकोड ब्लॉक में सीआरएस के आसपास ब्रेसिज़ का उपयोग करता हूं तो क्या मुझे ब्लॉक के अंदर या बाहर break रखना चाहिए?

case FOO: // 'break' inside 
    { 
    int i; 
    doStuff(); 
    break; 
    } 

case BAR: // 'break' outside 
    { 
    int i; 
    doStuff(); 
    } 
    break; 

धन्यवाद।

Answer 1

यह शैली का विषय है।

मैं इसे break को बंद करने के लिए बस इसे और अधिक पठनीय बनाने के लिए रखूंगा।

Answer 2

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

Answer 3

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

Answer 4

मैं आमतौर पर ब्रेसिज़ के अंदर break, इस तरह से रख:

switch (foo) { 
    case bar: { 
     int x = 5; 
     printf("%d\n", x); 
     break; 
    } 
    case baz: { 
     // ... 
     break; 
    } 
} 

हालांकि, बाद से यह मेरा नियम है कि मैं इसे (कोई यमक इरादा) को तोड़ने के लिए जब भी मैं चाहता हूँ मुक्त कर रहा हूँ।

Answer 5

मेरी राय पर आपको स्विच स्टेटमेंट्स में स्थानीय चर और ब्लॉक से बचना चाहिए। इसके अलावा आपको लंबे, या जटिल या यहां तक ​​कि कैस्केड स्विच स्टेटमेंट्स से बचना चाहिए। लेकिन अपवाद के बिना कोई नियम नहीं ... मैं ब्लॉक के बाद ब्रेक स्टेटमेंट लिखना पसंद करता हूं।

Answer 6

यह बाद में दिखाई देना चाहिए।

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

switch(value) 
{ 
    case 0: 
    { 
    // this ... 
    // that ... 
    // and the other ... 
    } 
    break; 
} 

संपादित पाठ नीचे

यह ज्यादातर पठनीयता और रख-रखाव में सुधार करने के लिए यहाँ एक उदाहरण है।

switch (value) 
{ 
    case 0: 
    // Do this... 
    // Do that... 
    break; 
    case 1: 
    //and the other... 
    break; 
} 

और

switch (value) 
{ 
    case 0: 
    // Do this... 
    // Do that... 
    if (ObjectWithinScope.Type == Fault) 
    break; 
    case 1: 
    //and the other... 
    break; 
} 

अब

switch (value) 
{ 
    case 0: 
    { 
    // Do this... 
    // Do that... 
    } 
    break; 
    case 1: 
    //and the other... 
    break; 
} 

और

switch (value) 
    { 
     case 0: 
     { 
     // Do this... 
     // Do that... 
     if (ObjectWithinScope.Type == Fault) 
     break; 
     } 
     case 1: 
     { 
     //and the other...   
     } 
     break; 
    } 

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

बस एक सूचक।

अब आप में से कुछ अभी भी सोच रहे हैं कि मैं क्या प्राप्त कर रहा हूं। यही पर है। विरासत कोड का एक टुकड़ा काम करना बंद कर दिया और कोई भी काम क्यों कर सकता है।यह सब तरह से संरचित कोड का एक टुकड़ा करने के लिए नीचे उबला हुआ निम्नलिखित:

switch (value) 
    { 
     case 0: 
     { 
     // Do this... 
     // Do that... 
     if (ObjectWithinScope.Type == Fault) 
     break; 
     } 
     case 1: 
     { 
     //and the other...   
     } 
     break; 
    } 

यह एक लंबे समय के लिए इस कोड नीचे पिन करने के लिए ले लिया है, लेकिन परिवर्तन लॉग की जाँच पर यह followws के रूप में मूल रूप से किया गया था:

switch (value) 
    { 
     case 0: 
     { 
     // Do this... 
     // Do that... 
     if (ObjectWithinScope.Type == Fault) 
      // *** A line of code was here *** 
     break; 
     } 
     case 1: 
     { 
     //and the other...   
     } 
     break; 
    } 

मान्य रूप से मूल कोड स्वयं के साथ संगत नहीं था, लेकिन घुंघराले ब्रैकेट के भीतर ब्रेक करके कोड संकलित किया गया था जब कोड की एक पंक्ति दुर्घटना से हटा दी गई थी। यदि ब्रेक ब्रैकेट के बाहर था तो उसके पास नहीं होगा।

Answer 7

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

मैं व्यक्तिगत रूप से बाद में पसंद करता हूं। तर्क यह है कि यह स्विच कथन की मशीनरी (कूदने, सामान निष्पादित करने और बाहर निकलने) के बीच कुछ अलगाव देता है, और ब्रेसिज़ के भीतर कोड जो पूरी तरह से मामले के 'कर' से जुड़ा होता है।

जैसे:

switch(value) 
{ 
    case 0: 
     { 
      // code here 
     } 
     break; 

    default: 
     { 
      assert(!"unhandled value in switch"); 
     } 
     break; 
} 

मैं केवल एक मामले के लिए {} का उपयोग करता है, तो यह स्थानीय चर की जरूरत है, लेकिन अगर मैं का उपयोग {} किसी भी मामले के लिए, मैं उन सभी मामलों पर डाल दिया।

मैं आमतौर पर हमेशा एक डिफ़ॉल्ट केस परिभाषित करता हूं कि कोई अप्रत्याशित मूल्य है या नहीं। यह आश्चर्यजनक है कि इनमें से एक कितनी बार एक लापता मामले की याद दिलाने के लिए आग लगती है।

Answer 8

यह शैली के लिए एक बात है, लेकिन मैं इसे बाद डाल के रूप में मैं के रूप में परिभाषा को समझने:

switch (variable) 
{ 
    case expression: 
     statement; 
     break; 
    default: 
     statement; 
     break; 
} 

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

selection-statement: 
    switch (expression) statement 

labeled-statement: 
    case constant-expression : statement 
    default : statement 

कौन सा संकेत मिलता है कि इसके अंदर होना चाहिए:

हालांकि, मैं केवल के रूप में माइक्रोसॉफ्ट के माध्यम से वास्तविक परिभाषा के लिए प्रलेखन पा सकते हैं।

हालांकि, मुझे लगता है कि बाहरी पाठकों के परिप्रेक्ष्य से स्पष्ट है, लेकिन यह निश्चित रूप से व्यक्तिपरक है।

Answer 9

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

switch (some_var) { 
     case 1: { 
      // lot of code here 
     } break; 
     case 2: /* one call */ break; 
     case 3: /* one call */ break; 
     case 4: { 
      // lot of code here again 
     } break; 
    } 

Answer 10

हर कोई इससे सहमत हैं कि हम switch/case... मशीनरी और प्रत्येक मामले में प्रदर्शन वास्तविक कार्यों के बीच एक स्पष्ट रूप से पहचानने योग्य भेद चाहते हैं।

वजह, जब तक कि वहाँ वास्तव में लगभग कुछ भी नहीं प्रत्येक मामले में चल रही (सरल काम या तो) है, मैं एक मात्र डिस्पैचर के रूप में switch उपयोग करने के लिए, और सहायक कार्यों के लिए 'असली' चीजों को सौंपने का सुझाव दें।यह स्वचालित रूप से केस-स्थानीय चर के मुद्दे को हल करता है, और पूरी तरह से ब्रेसिज़ की आवश्यकता को रोकता है।

switch(operation) { 
    case cnegation: r = -value; break; 
    case cinversion: r = 1./r; break; 
    case cfaculty: { 
    double r = value; 
    while(value != 1) 
     r *= --value; 
    } 
    break; 
} 

तो बन चाहिए

switch(operation) { 
    case cnegation : r = negate (value) ; break; 
    case cinversion: r = invert (value) ; break; 
    case cfaculty : r = faculty(value) ; break; 
} 

Answer 11

वहाँ एक बहुत ही मामले प्रति एक कथन का उपयोग, और कभी ब्रेसिज़ का उपयोग कर की शैली के लिए कहा जा रहा है। उदाहरण के लिए:

 
switch(cond) { 
default: foo(); break; 
case 0: bar(); break; 
case 1: baz(); break; 
} 

इस शैली का उपयोग करके, आपका प्रश्न मंथन है।

Answer 12

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

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

switch(blah) 
{ 
case 1: 
    // do one thing 
    break; 

case 2: 
    doManyThings(); 
    break; 

default: 
    // something 
    break; 
} 

Answer 13

रियल उत्तर: संकलक परवाह नहीं है। यह वरीयता का मामला है।

मैं उन्हें अंदर google style guide की तरह रखा,।

हैं ब्रेसिज़ का उपयोग कर, मैं उद्घाटन ब्रेस समापन ब्रेस (जो गूगल से अलग है) के रूप में एक ही स्तंभ पर होना चाहते।

switch (var) { 
    case 0: 
    { 
    ...  
    break; 
    } 
    case 1: 
    { 
    ... 
    break; 
    } 
    default: 
    assert(false); 
} 

Answer 14

मेरा ले लो ... उदाहरण के लिए नीचे देखें।

एक स्विच के सभी मामलों को इंडेंट करें और कीवर्ड switch के तहत स्विच का समापन ब्रैकेट रखें, जैसे कोई if कथन में करेगा। जब भी आवश्यक हो, प्रत्येक case कथन के लिए एक ही नियम: case कथन के बाद सेमी-कॉलम के बाद खुले ब्रैकेट्स और उन्हें case कीवर्ड के नीचे बंद करें, फिर case विवरणों में से प्रत्येक की सामग्री को break समेत प्रस्तुत करें।

यह लगातार (खरोज और कोष्ठक प्लेसमेंट) और छोटी (case बयान के अनुसार कोड का कोई 5-10 से ज्यादा लाइनों रखें। जटिल परियोजनाओं क्योंकि उन में बहुत अधिक कोड के साथ बुरी तरह से इंडेंट switch बयान के विफल रहे हैं।

switch (number) { 

     case 1: 
      logFileStderr(VERBOSE, "MESSAGE: switch without brackets...\n"); 
      break; 

     case 2: { 
      logFileStderr(VERBOSE, "MESSAGE: switch with brackets...\n"); 
      break; 
     } 

     default: 
      logFileStderr(VERBOSE, "WARNING: Unknown option...\n"); 
      break; 
    }