क्या लूप में ब्रेक का उपयोग करना एक बुरा अभ्यास है? [बन्द है]

Question

क्या लूप के अंदर breakबयान का उपयोग करना एक बुरा अभ्यास है ?for

कहो, मैं एक सरणी में मान खोज रहा हूं। लूप के break;लिए बाहर की तुलना करें और जब लूप से बाहर निकलने के लिए मान मिलता है ।

क्या यह एक बुरा अभ्यास है? मैंने उपयोग किए गए विकल्प को देखा है: एक चर को परिभाषित करें vFoundऔर इसे सही पर सेट करें जब मूल्य पाया जाता है और बयान की स्थिति vFoundमें जांच करता है for। लेकिन क्या इस उद्देश्य के लिए एक नया चर बनाना आवश्यक है?

मैं लूप के लिए एक सामान्य सी या सी ++ के संदर्भ में पूछ रहा हूं।

पुनश्च: MISRA कोडिंग दिशानिर्देश ब्रेक का उपयोग करने के खिलाफ सलाह देते हैं।

Comments

न रखें breakके रूप में एक ही लीग में goto:)

— BoltClock

ईआर, मैंने उन्हें एक ही लीग में नहीं रखा है, क्योंकि ... मुझे सही से याद है तो MISRA के नियम ब्रेक को निर्दिष्ट करते हैं।

— किकी

एक ही कारण है कि मैं एक लूप के अंदर ब्रेक का उपयोग नहीं करने के बारे में सोच सकता हूं, जब आपको अभी भी अधिक वस्तुओं को संसाधित करना होगा जो कि आप जो कर रहे हैं उसका परिणाम बदल सकता है ...

— यूनुस

MISRA नियमों में ढील दी गई है: misra.org.uk/forum/viewtopic.php?f=75&t=298

— जोहान कोटलिंस्की

डुप्लिकेट: प्रोग्रामर.स्टैकएक्सचेंज.

— फेलिप

Answer 1

यहाँ बहुत सारे उत्तर हैं, लेकिन मैंने अभी तक इसका उल्लेख नहीं किया है:

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

यदि एक लूप बहुत बड़ा हो रहा है, तो लूप के बजाय एक या अधिक नामांकित फ़ंक्शन कॉल का उपयोग करें। ऐसा करने से बचने का एकमात्र वास्तविक कारण अड़चन प्रसंस्करण के लिए है।

Comments

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

— Jay

एक और मुद्दा यह है कि ब्रेक लगाना और रीफैक्टरिंग के साथ समस्याएं पैदा करना। यह एक संकेत हो सकता है कि यह एक बुरा अभ्यास है। यदि कथनों का उपयोग किया जाता है तो कोड की मंशा भी स्पष्ट है।

— एड ग्रीव्स

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

— डेविडआरआर

Answer 2

नहीं, ब्रेक सही समाधान है।

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

Comments

माना। खासकर यदि आप एक से अधिक शर्तों के तहत लूप से बाहर निकलना चाह रहे हैं। एक लूप छोड़ने के लिए बूलियन वास्तव में भ्रमित हो सकता है।

— रोनटोलॉजिस्ट

यही कारण है कि मैं gotoस्तर 2 + नेस्टेड छोरों को तोड़ने का उपयोग करता हूं - क्योंकि वहाँ नहीं हैbreak(level)

— Петър Петров

मैं एक फ़ंक्शन में लूप कोड डालना चाहता हूं, और बस वापस लौटता हूं। यह गोटो से बचा जाता है, और आपके कोड को छोटे टुकड़ों में तोड़ देता है।

— डेव ब्रैंटन

Answer 3

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

Answer 4

का उपयोग breakकरने के साथ ही continueएक में forपाश बिल्कुल ठीक है।

यह कोड को सरल करता है और इसकी पठनीयता में सुधार करता है।

Comments

हाँ .. एक समय के लिए मुझे यह विचार पसंद नहीं आया और इसके आसपास कोडित किया गया था, लेकिन इससे पहले कि मुझे एहसास हुआ कि इसमें बहुत समय नहीं लगा ... "वर्कअराउंड" अक्सर एक रखरखाव दुःस्वप्न था। खैर, एक बुरा सपना नहीं है, लेकिन अधिक त्रुटि-प्रवण।

— मेटलएमिस्टर

Answer 5

बुरी प्रथा से दूर, पायथन (और अन्य भाषाएं?) ने forलूप संरचना को विस्तारित किया, इसलिए इसका हिस्सा केवल तभी निष्पादित होगा जब लूप नहीं होता है break ।

for n in range(5):
    for m in range(3):
        if m >= n:
            print('stop!')
            break
        print(m, end=' ')
    else:
        print('finished.')

आउटपुट:

stop!
0 stop!
0 1 stop!
0 1 2 finished.
0 1 2 finished.

---

बिना समतुल्य कोड breakऔर वह काम else:

for n in range(5):
    aborted = False
    for m in range(3):
        if not aborted:
            if m >= n:
                print('stop!')
                aborted = True
            else:            
                print(m, end=' ')
    if not aborted:
        print('finished.')

Comments

ऊह, मुझे यह पसंद है और कभी-कभी सी। नाइस सिंटैक्स में भी इसके लिए कामना की है, जिसे भविष्य की सी-लाइक भाषा में अस्पष्टता के बिना अनुकूलित किया जा सकता है।

— सुपरकैट

"सी-

— लाइक

Answer 6

ब्रेक स्टेटमेंट का उपयोग करने में स्वाभाविक रूप से कुछ भी गलत नहीं है लेकिन नेस्टेड लूप भ्रमित हो सकते हैं। पठनीयता में सुधार करने के लिए कई भाषाएं ( कम से कम जावा करता है ) लेबल को तोड़ने का समर्थन करती हैं जो पठनीयता में सुधार करेगी।

int[] iArray = new int[]{0,1,2,3,4,5,6,7,8,9};
int[] jArray = new int[]{0,1,2,3,4,5,6,7,8,9};

// label for i loop
iLoop: for (int i = 0; i < iArray.length; i++) {

    // label for j loop
    jLoop: for (int j = 0; j < jArray.length; j++) {

        if(iArray[i] < jArray[j]){
            // break i and j loops
            break iLoop;
        } else if (iArray[i] > jArray[j]){  
            // breaks only j loop
            break jLoop;
        } else {
            // unclear which loop is ending
            // (breaks only the j loop)
            break;
        }
    }
}

मैं कहूंगा कि ब्रेक (और वापसी) बयानों से अक्सर साइक्लोमैटिक जटिलता बढ़ जाती है जिससे कोड को साबित करना कठिन हो जाता है जो सभी मामलों में सही काम कर रहा है।

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

Comments

साइक्लोमैटिक जटिलता के लिए +1।

— sp00m

.NET प्रोग्रामर जटिल लूप के संभावित विकल्प के रूप में LINQ के उपयोग का पता लगाना चाहते हैं for।

— डेविड आरआर

Answer 7

ब्रेक का उपयोग करने के लिए एक पूरी तरह से स्वीकार्य बयान है (इसलिए जारी है , btw)। यह सभी कोड पठनीयता के बारे में है - जब तक आपके पास ओवरलोप्लेटेड लूप नहीं हैं और इस तरह, यह ठीक है।

ऐसा नहीं है कि वे गोटो के समान लीग थे । :)

Comments

मैंने देखा है यह तर्क दिया है कि एक को तोड़ने बयान है प्रभावी रूप से एक गोटो ।

— ग्लेनट्रॉन

गोटो के साथ समस्या यह है कि आप इसे कहीं भी इंगित कर सकते हैं। दोनों ही कोड की प्रतिरूपकता को तोड़ते और जारी रखते हैं। यह तर्क प्रत्येक कार्य के लिए एकल निकास बिंदु होने के समान स्तर पर है।

— ज़ाचरी येट्स

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

— ग्लेनट्रॉन

@glenatron गोटो के साथ समस्या गोटो स्टेटमेंट नहीं है, यह उस लेबल की शुरूआत है जो कि गोटो की समस्या है। आप एक गोटो बयान पढ़ते हैं, नियंत्रण प्रवाह के बारे में कोई अनिश्चितता नहीं है। जब आप एक लेबल पढ़ते हैं, तो नियंत्रण प्रवाह के बारे में बहुत अनिश्चितता होती है (जहां सभी लेबल हैं जो इस लेबल पर नियंत्रण स्थानांतरित करते हैं)। एक ब्रेक स्टेटमेंट एक लेबल पेश नहीं करता है, इसलिए यह किसी भी नई जटिलताओं का परिचय नहीं देता है।

— स्टीफन सी। स्टील

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

— सुपरकैट

Answer 8

सामान्य नियम: यदि किसी नियम का पालन करने के लिए आपको कुछ और अजीब और पढ़ने में मुश्किल होती है, तो नियम को तोड़ना, फिर नियम को तोड़ना।

लूपिंग के मामले में जब तक आप कुछ नहीं पाते हैं, आप अलग-अलग पाए जाने की समस्या में भाग लेते हैं, जब आप बाहर निकलते हैं तो पाया नहीं जाता है। अर्थात्:

for (int x=0;x<fooCount;++x)
{
  Foo foo=getFooSomehow(x);
  if (foo.bar==42)
    break;
}
// So when we get here, did we find one, or did we fall out the bottom?

तो ठीक है, आप एक ध्वज सेट कर सकते हैं, या एक "पाया" मान को शून्य करने के लिए आरंभ कर सकते हैं। परंतु

इसलिए सामान्य तौर पर मैं अपनी खोजों को कार्यों में धकेलना पसंद करता हूं:

Foo findFoo(int wantBar)
{
  for (int x=0;x<fooCount;++x)
  {
    Foo foo=getFooSomehow(x);
    if (foo.bar==wantBar)
      return foo;
  }
  // Not found
  return null;
}

यह भी कोड को अव्यवस्थित करने में मदद करता है। मुख्य पंक्ति में, "ढूंढें" एक एकल कथन बन जाता है, और जब स्थितियां जटिल होती हैं, तो वे केवल एक बार लिखे जाते हैं।

Comments

बिल्कुल वही जो मैं कहना चाहता था। अक्सर जब मैं अपने आप को उपयोग करते हुए पाता हूं break, तो मैं कोड को किसी फ़ंक्शन में रिफलेक्टर करने का कोई तरीका खोजने की कोशिश करता हूं, ताकि मैं returnइसके बजाय उपयोग कर सकूं ।

— रेने सारसो

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

— vascowhite

आपका उत्तर कई रिटर्न स्टेटमेंट का उपयोग करने की सलाह का पता लगाने के लिए कुछ संकेत दे सकता है ।

— डेविड आरआर

Answer 9

यह भाषा पर निर्भर करता है। जबकि आप संभवतः यहां बूलियन चर की जांच कर सकते हैं:

for (int i = 0; i < 100 && stayInLoop; i++) { ... }

किसी सरणी पर पुनरावृत्ति होने पर ऐसा करना संभव नहीं है:

for element in bigList: ...

वैसे भी, breakदोनों कोड को अधिक पठनीय बनाते हैं।

Answer 10

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

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

Comments

यदि कोई ज्ञात अधिकतम संख्या में पुनरावृत्तियों है, तो "for" लूप अक्सर अच्छा होता है। यह कहा गया है, एक समय (1) लूप कभी-कभी ऐसे परिदृश्य में बेहतर होता है जहां कोई वस्तु खोज रहा होता है और यदि वह मौजूद नहीं है तो इसे बनाने की योजना है। उस स्थिति में, यदि कोड आइटम को खोजता है तो वह एक सीधा ब्रेक करता है, और यदि यह सरणी के अंत को हिट करता है तो यह एक नया आइटम बनाता है और फिर एक ब्रेक करता है।

— सुपरकैट

दिए गए उदाहरण में - एक कुंजी के लिए एक सरणी के माध्यम से खोज करना, लूप के लिए उचित मुहावरेदार निर्माण है। आप किसी सरणी से चलने के लिए थोड़ी देर के लूप का उपयोग नहीं करते हैं। आप लूप के लिए उपयोग करते हैं। (या यदि उपलब्ध हो तो प्रत्येक लूप के लिए)। आप इसे अन्य प्रोग्रामर के सौजन्य से करते हैं, क्योंकि वे "for (int i = 0; i <.length; i ++) {}" निर्माण "को" सरणी के माध्यम से तुरंत "पहचानते हैं, इस निर्माण के लिए एक विराम जोड़ते हैं। बस एक "जल्दी छोड़ो अगर तुम कर सकते हो" बयान।

— क्रिस कॉडमोर

Answer 11

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

• ब्लॉक के शीर्ष पर अधिगृहीत एक संसाधन को तल पर छोड़ा जा सकता है (यह forछोरों के अंदर के ब्लॉक के लिए भी सही है ), लेकिन जब "समयपूर्व" निकास एक breakबयान ("आधुनिक" के कारण होता है) तब गलती से छोड़ दिया जा सकता है। C ++, "RAII" का उपयोग इसे विश्वसनीय और अपवाद-सुरक्षित तरीके से संभालने के लिए किया जाता है: मूल रूप से, ऑब्जेक्ट डिस्ट्रक्टर्स मुक्त संसाधनों से मज़बूती से कोई फर्क नहीं पड़ता कि कोई गुंजाइश कैसे निकलती है)

• कोई भी forबयान में सशर्त परीक्षा को बदल सकता है बिना यह ध्यान दिए कि बाहर निकलने की अन्य शर्तें हैं

• ndim के उत्तर में देखा गया है कि कुछ लोग breakअपेक्षाकृत स्थिर लूप रन-टाइम को बनाए रखने के लिए s से बच सकते हैं , लेकिन आप breakबूलियन अर्ली-एग्जिट कंट्रोल वेरिएबल के उपयोग के खिलाफ तुलना कर रहे थे, जहां यह पकड़ नहीं है

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

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

Comments

खैर, हाँ, लेकिन फिर मैंने उन लोगों के कोड में कीड़े देखे हैं जिन्होंने धार्मिक रूप से बचने की कोशिश की थी break। इससे बचा गया लेकिन उन परिस्थितियों से सोचने में असफल रहा जिन्होंने ब्रेक के उपयोग को प्रतिस्थापित किया।

— टॉम ज़ातो -

Answer 12

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

यद्यपि आप vFoundचर का उपयोग करना चाहते हैं जब आप लूप के बाहर की जांच करना चाहते हैं कि क्या मूल्य सरणी में पाया गया था। इसके अलावा, एक स्थिरता के दृष्टिकोण से, बाहर निकलने के मानदंडों का संकेत देने वाला एक सामान्य ध्वज उपयोगी हो सकता है।

Answer 13

मैंने उस कोडबेस पर कुछ विश्लेषण किया जो मैं वर्तमान में (जावास्क्रिप्ट की 40,000 लाइनों) पर काम कर रहा हूं।

मुझे उनमें से केवल 22 breakकथन मिले :

• 19 का इस्तेमाल switchबयानों के अंदर किया गया (हमारे पास कुल 3 स्विच स्टेटमेंट हैं!)।
• 2 का उपयोग forलूप के अंदर किया गया था - एक कोड जिसे मैंने तुरंत अलग-अलग कार्यों में रिफैक्ट होने के लिए वर्गीकृत किया था और returnबयान के साथ बदल दिया गया था ।
• लूप के breakअंदर फाइनल के लिए while... मैं git blameयह देखने के लिए दौड़ा कि यह बकवास किसने लिखी है!

इसलिए मेरे आंकड़ों के अनुसार: यदि breakइसका उपयोग बाहर किया जाता है switch, तो यह एक कोड गंध है।

मैंने continueबयान भी खोजे । कोई नहीं मिला।

Answer 14

मुझे कोई कारण नहीं दिखता कि यह एक बुरा व्यवहार क्यों होगा कि आप उस बिंदु पर STOP प्रसंस्करण को पूरा करना चाहते हैं।

Answer 15

एम्बेडेड दुनिया में, वहाँ कोड का एक बहुत कुछ है जो निम्नलिखित निर्माण का उपयोग करता है:

    while(1)
    { 
         if (RCIF)
           gx();
         if (command_received == command_we_are_waiting_on)
           break;
         else if ((num_attempts > MAX_ATTEMPTS) || (TickGet() - BaseTick > MAX_TIMEOUT))
           return ERROR;
         num_attempts++;
    }
    if (call_some_bool_returning_function())
      return TRUE;
    else
      return FALSE;

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

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

Comments

क्या आप इसे विस्तार से समझा सकते हैं? यह मुझे लगता है जैसे कि लूप बिल्कुल कुछ भी नहीं करता है ... जब तक continueकि आवेदन तर्क के अंदर बयान न हों । वहां हैं?

— रेने सारसो

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

— नैट

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

— नैट

"अगर (call_some_bool_returning_function ()) TRUE लौटाएं, तो FALSE लौटें;" सिर्फ "वापसी call_some_bool_returning_function ()" हो सकता है

— फ्रैंक

Answer 16

आपके उपयोग के मामले पर निर्भर करता है। ऐसे अनुप्रयोग हैं जहाँ लूप के रनटाइम को स्थिर रखने की आवश्यकता होती है (जैसे कुछ समय की कमी को पूरा करने के लिए, या अपने डेटा इंटर्न को समय आधारित हमलों से छिपाने के लिए)।

उन मामलों में यह भी एक झंडा सेट करने के लिए समझ में आता है और केवल झंडा मूल्य की जांच के बाद सभी forलूप पुनरावृत्तियों वास्तव में चला रहे हैं। बेशक, लूप पुनरावृत्तियों के लिए सभी को कोड चलाने की आवश्यकता होती है जो अभी भी उसी समय के बारे में लेता है।

यदि आप रन टाइम की परवाह नहीं करते हैं ... कोड का उपयोग करें break;और continue;कोड को पढ़ने में आसान बनाएं।

Comments

यदि समय महत्वपूर्ण है, तो आप कुछ नींद लेने से बेहतर हो सकते हैं और सिस्टम संसाधनों को बचाने की तुलना में प्रोग्राम को ज्ञात-से-बेकार संचालन करने दे सकते हैं।

— Bgs

Answer 17

पर मिश्रा 98 नियम, कि सी देव में मेरी कंपनी पर प्रयोग किया जाता है, को तोड़ने बयान नहीं किया जाएगा ...

संपादित करें: MISRA '04 में ब्रेक की अनुमति है

Comments

वास्तव में मैंने यह सवाल क्यों पूछा! मुझे कोई अच्छा कारण नहीं लगता कि ऐसा नियम कोडिंग गाइडलाइन के रूप में क्यों है। इसके अलावा, जैसा कि यहां बाकी सभी ने कहा, विराम; बेहतर लग रहा है।

— किकी

मुझे नहीं पता कि यह निषिद्ध क्यों है (मेरे बारे में अधिक चतुर व्यक्ति इसके बारे में सोच रहा है ...), लेकिन पठनीयता के लिए विराम (और एकाधिक वापसी) बेहतर हैं (मेरी राय में, लेकिन मेरी राय कॉर्पोरेट नियम नहीं हैं ... )

— बेनोइट

उह, MISRA नियम ब्रेक स्टेटमेंट के उपयोग की अनुमति देते हैं: misra.org.uk/forum/viewtopic.php?f=75&t=298

— luis.espinal

हमने MISRA 98 नियमों का उपयोग किया है ... यह सटीक है कि MISRA 2004 नियमों को बदल देता है

— BenoISt

Answer 18

बेशक, break;लूप या foreach पाश के लिए बंद करने के लिए समाधान है। मैंने इसे फॉर्च में और लूप के लिए php में इस्तेमाल किया और काम करते पाया।

Answer 19

मैं असहमत हूं!

आप अपने स्वयं के बनाने के लिए लूप के लिए अंतर्निहित कार्यक्षमता की उपेक्षा क्यों करेंगे? आपको पहिया को सुदृढ़ करने की आवश्यकता नहीं है।

मुझे लगता है कि लूप के लिए अपने चेक को अपने शीर्ष पर रखना अधिक समझदारी है

for(int i = 0; i < myCollection.Length && myCollection[i].SomeValue != "Break Condition"; i++)
{
//loop body
}

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

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
//loop body
}

इस तरह आप सब कुछ करने के लिए एक फ़ंक्शन लिख सकते हैं और बहुत क्लीनर कोड बना सकते हैं।

for(int i = 0; i < myCollection.Length && (i == 0 ? true : myCollection[i-1].SomeValue != "Break Condition"); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

या यदि आपकी स्थिति जटिल है, तो आप उस कोड को भी स्थानांतरित कर सकते हैं!

for(int i = 0; i < myCollection.Length && BreakFunctionCheck(i, myCollection); i++)
{
    DoAllThatCrazyStuff(myCollection[i]);
}

"व्यावसायिक कोड" जो विराम से भरा है, वास्तव में मेरे लिए पेशेवर कोड की तरह नहीं है। यह आलसी कोडिंग की तरह लगता है;)

Comments

आलसी कोडिंग आईएस पेशेवर कोड है :)

— जेसन

केवल अगर इसे बनाए रखने के लिए बट में दर्द नहीं है :)

— बिफ मागरिफ

मैं "जीटीएफओ एएसएपी" का अभ्यास करता हूं। यही है, अगर मैं किसी संरचना को सफाई से बाहर कर सकता हूं, तो मुझे जल्द से जल्द ऐसा करना चाहिए, और उस स्थिति के करीब होना चाहिए जो निकास को निर्दिष्ट करता है।

— क्रिस कुडमोर

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

— Biff MaGriff

Haha। इस तथ्य पर विचार करें कि हतोत्साहित करने वाले अधिकांश लोग breakतर्क देते हैं कि यह कोड पठनीयता के लिए है। अब फिर से ऊपर की छोरों में पागल 5 मील लंबी स्थिति को देखें ...

— Tomáš Zato - Reinstate Monica