स्विच केस इंडेंटेशन

Question

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

switch(keyCode) { 
     case TVKEY.KEY_EXIT: 
      // do something 
     case TVKEY.KEY_ENTER: 
      if(firstTest)) { // User chose to steal token 
       // do something 
      } else if(secondTest)) { 
       // other condition 
      } else { 
       // do else 
      } 
      break; 
     default: 
      // do default stuff 
      break; 

    } 

सूचना पिछले contional के ब्रैकेट समापन स्विच ब्रैकेट से में दो स्तरों है:

यहाँ मैं कर दिया गया है कि यह कैसे कर रही है (मेरे सवाल का अधिक दृश्य होने की जरूरत है तो) का एक उदाहरण है। गलत? बहुत उग्र?

Answer 1

तो बुनियादी तौर पर आप बहस कर रहे हैं

और

के बीच

switch(x) { 
    case 1: if (something) { 
      } 
    case 2: if (other) { 
      } 
} 

switch (x) { 
case 1: if (something) { 
     } 
case 2: if (other) { 
     } 
} 

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

ईटीए:

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

बेशक, इंडेंटेशन पवित्र युद्ध कर सकता है: टैब/स्पेस? टैब 4 वर्णों पर बंद हो जाता है? 8 अक्षर? कांटा? स्पून?

Answer 2

मेरी प्राथमिकता caseswitch के समान कॉलम में शुरू होने वाली है।

1. कोड खरोज अत्यधिक नहीं है:

   मेरे कारणों दो गुना कर रहे हैं।

2. यह if, else if, else खंडों की संरचना को दर्शाता है। शायद हर कोई सोचता है कि if और else को गठबंधन किया जाना चाहिए क्योंकि वे एक सशर्त निर्माण के तर्क नियंत्रण कोड का हिस्सा हैं। switch और case भी एक सशर्त निर्माण के तर्क नियंत्रण कोड का स्पष्ट रूप से हिस्सा हैं और स्थिरता के लिए इतना गठबंधन होना चाहिए। switch-case निर्माण के बाद if-else निर्माण के रूप में फिर से लिखा जा सकता है और जब संकलित दोनों एक ही निम्न स्तर कोड प्रदान करेंगे।

Answer 3

मेरे 2 सेंट, क्योंकि मैं अभी इस मुद्दे का सामना करना पड़ता है और एक समाधान है कि मैं पर्याप्त साझा करना चाहते =) पाया

switch (mode) 
{ 
    case Value1: 
    { 
     Ptr_t ptr1 = ...; 
     return ptr1; 
    } 

    case Value2: 
    { 
     Ptr_t ptr2 = ...; 
     return ptr2; 
    } 

    default: 
    { 
     return nullptr; 
    } 
} 

स्पष्टीकरण:

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

2. पठनीयता! मुझे यह सच में पता चलता है कि यहां क्या हो रहा है, इसलिए यह वास्तव में एक अच्छा मुद्दा है। कुछ अनावश्यक इंडेंटेशन है, लेकिन जब यह पठनीयता में सुधार करता है तो कौन परवाह करता है?

3. case और default accolades संरेखण अन्य नियंत्रण संरचनाओं की तरह दिखता है, इसलिए यह नए पाठकों के लिए आश्चर्य की बात नहीं है।

यह वास्तविक/निश्चित उत्तर नहीं है, केवल एक व्यक्तिगत विकल्प है।

Answer 4

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

मुझे अब तक का एकमात्र नकारात्मक पक्ष मिला है: ऐसा लगता है कि ऐसा कोई ऑटो ब्यूटीफायर टूल नहीं है।

यह कैसे सवाल से कोड होगा

switch (keyCode) { 
    case TVKEY.KEY_EXIT: // indented by one space against switch 
    // do something 
    case TVKEY.KEY_ENTER: 
    if (firstTest) { // indented by one tab sizes against switch 
     // do something 
    } else if (secondTest) { 
     // other condition 
    } else { 
     // do else 
    } 
    break; // empty line visualize block, so you know code is not passing to next case 

default: 
    // do default stuff 
    break; 

}