क्या `ब्रेक` और` जारी` खराब प्रोग्रामिंग प्रथाएं हैं?

Question

मेरे बॉस ने गैर-प्रोग्रामर का उल्लेख किया है जो खराब प्रोग्रामर उपयोग करते हैं breakऔर continueलूप में हैं।

मैं हर समय उनका उपयोग करता हूं क्योंकि वे समझ में आते हैं; मुझे आपको प्रेरणा दिखाने दें:

function verify(object) {
    if (object->value < 0) return false;
    if (object->value > object->max_value) return false;
    if (object->name == "") return false;
    ...
}

यहाँ मुद्दा यह है कि पहले फ़ंक्शन जाँचता है कि स्थितियाँ सही हैं, फिर वास्तविक कार्यक्षमता निष्पादित करता है। IMO लूप के साथ लागू होता है:

while (primary_condition) {
    if (loop_count > 1000) break;
    if (time_exect > 3600) break;
    if (this->data == "undefined") continue;
    if (this->skip == true) continue;
    ...
}

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

Comments

यह भूलने के लिए बहुत कुछ नहीं करता कि कौन क्या करता है।

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

— orj

मैं दृढ़ता से पर्याप्त कोडिंग की इस शैली के लिए अपना समर्थन नहीं दे सकता। नेस्टेड कंडीशन के कई स्तर इस दृष्टिकोण से बहुत खराब हैं। मैं आमतौर पर कोडिंग शैली के बारे में आतंकवादी नहीं हूं, लेकिन यह मेरे लिए लगभग एक सौदा-ब्रेकर है।

— एमिल एच

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

— साकिस

खराब प्रोग्रामर ब्रेक का उपयोग करते हैं और इसका मतलब यह नहीं है कि अच्छे प्रोग्रामर नहीं हैं। खराब प्रोग्रामर अगर और साथ ही उपयोग करते हैं।

— मौविसील

Answer 1

जब एक ब्लॉक की शुरुआत में उपयोग किया जाता है, तो पहले किए गए चेक के रूप में, वे पूर्व शर्त की तरह काम करते हैं, इसलिए यह अच्छा है।

जब ब्लॉक के बीच में उपयोग किया जाता है, तो चारों ओर कुछ कोड के साथ, वे छिपे हुए जाल की तरह काम करते हैं, इसलिए यह खराब है।

Comments

@ अस्वीकरण: यह तर्क दिया जा सकता है कि किसी भी दिनचर्या जिसमें कई निकास बिंदु हैं, एक खराब-तथ्यपूर्ण दिनचर्या है। एक सही ढंग से फैली हुई दिनचर्या को एक काम और एक ही करना चाहिए।

— बिट-टिडलर

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

— मैथ्यू एम।

@ मैथ्यू मैं सहमत हूं। एक ब्लॉक से बाहर निकलें जब आपको एक परिणाम प्राप्त होता है जो ब्लॉक के उद्देश्य को पूरा करता है।

— इवान प्लाइस

@ बिट-ट्विडलर - एकल-निकास-बिंदु सिद्धांत एकल-जिम्मेदारी-सिद्धांत से अलग है। मैं इस बात से सहमत नहीं हूं कि जाँच हमेशा एक ही ज़िम्मेदारी से अलग है। वास्तव में "एकल जिम्मेदारी" हमेशा मुझे एक व्यक्तिपरक शब्द के रूप में प्रभावित करती है। उदाहरण के लिए, एक द्विघात-सॉल्वर में, विवेचक की गणना एक अलग जिम्मेदारी होनी चाहिए? या पूरे द्विघात सूत्र एक ही जिम्मेदारी हो सकते हैं? मेरा तर्क है कि यह इस बात पर निर्भर करता है कि क्या आपके पास विभेदक के लिए एक अलग उपयोग है - अन्यथा, इसे एक अलग जिम्मेदारी के रूप में व्यवहार करना संभवतः अत्यधिक है।

— स्टीव

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

— Klaim

Answer 2

आप डोनाल्ड नुथ के 1974 के पेपर स्ट्रक्चर्ड प्रोग्रामिंग को स्टेट्स में जाने के साथ पढ़ सकते हैं , जिसमें वे चर्चा करते हैं go toकि इसके विभिन्न उपयोग संरचनात्मक रूप से वांछनीय हैं। वे breakऔर continueबयानों के बराबर शामिल हैं ( go toवहाँ के उपयोग में से कई अधिक सीमित निर्माण में विकसित किए गए हैं)। क्या आपके बॉस को नूथ को बुरा प्रोग्रामर कहने का प्रकार है?

(उदाहरणों ने मुझे दिलचस्पी दी है। आमतौर पर, breakऔर continueऐसे लोगों को नापसंद किया जाता है जो एक प्रविष्टि और किसी भी कोड के टुकड़े से बाहर निकलना पसंद करते हैं, और उस तरह का व्यक्ति कई returnबयानों पर भी भौंकता है ।)

Comments

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

— बिट-ट्विडलर

पास्कल के पास भी नेस्टेड फ़ंक्शन थे। बस 'कह ...

— Shog9

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

— डंक

@ बिट-ट्विडलर: मैं इसके बारे में निश्चित नहीं हूं। मैं आज भी पास्कल का उपयोग कर रहा हूं, और मैं आमतौर पर "सिंगल एंट्री सिंगल एग्जिट" या कम से कम सिंगल-एग्जिट भाग को कार्गो पंथ प्रोग्रामिंग के रूप में मानता हूं। मैं तो बस पर विचार Break, Continueऔर Exitमेरी पिटारे में औजार के रूप में; मैं उनका उपयोग करता हूं जहां यह कोड का पालन करना आसान बनाता है, और उनका उपयोग न करें जहां यह चीजों को पढ़ने के लिए कठिन बना देगा।

— मेसन व्हीलर

@ बिट-ट्विडलर: आमीन। मैं यह भी जोड़ूंगा कि एक बार जब आप उस ब्लॉक को आसानी से ऑन-स्क्रीन फिट कर लेंगे, तो कई एक्ज़िट पॉइंट्स कम परेशानी वाले हो जाएंगे।

— Shog9

Answer 3

मैं नहीं मानता कि वे बुरे हैं। यह विचार कि वे खराब हैं, संरचित प्रोग्रामिंग के दिनों से आता है। यह इस धारणा से संबंधित है कि एक फंक्शन में एक एंट्री पॉइंट और एक एग्जिट पॉइंट होना चाहिए, यानी केवल एक returnफंक्शन प्रति।

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

यदि आपका कार्य बहुत छोटा है, यदि आपके पास एक लूप है, या सबसे खराब दो नेस्टेड लूप हैं, और यदि लूप बॉडी बहुत कम है, तो यह बहुत स्पष्ट है कि क्या है breakया क्या continueकरता है। यह भी स्पष्ट है कि कई returnकथन क्या करते हैं।

इन मुद्दों को रॉबर्ट सी। मार्टिन द्वारा "क्लीन कोड" और मार्टिन फाउलर द्वारा "रिफैक्टिंग" में संबोधित किया गया है।

Comments

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

— दिमा

@ मिखाइल: साइक्लोमैटिक जटिलता आम तौर पर एसएलओसी के साथ बहुत दृढ़ता से सहसंबद्ध है, जिसका अर्थ है कि सलाह को "लंबे कार्यों को न लिखने" के लिए सरल बनाया जा सकता है।

— जॉन आर। स्ट्रॉहम

एकल निकास बिंदु का विचार व्यापक रूप से गलत है। एक बार, फ़ंक्शन को अपने कॉलर को वापस नहीं करना पड़ता था। वे किसी अन्य स्थान पर लौट सकते थे। यह आमतौर पर असेंबली भाषा में किया गया था। फोरट्रान ने इसके लिए एक विशेष निर्माण किया था; आप एम्परसैंड से पहले दिए गए एक कथन संख्या में पास हो सकते हैं CALL P(X, Y, &10), और त्रुटि के मामले में, फ़ंक्शन कॉल के बिंदु पर लौटने के बजाय, उस कथन पर नियंत्रण पारित कर सकता है।

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

उदाहरण के लिए, लुका के साथ देखा गया @kevincline।

— Qix डे

@cjsimon आपको मिल गया। न केवल कार्य छोटा होना चाहिए। कक्षाएं भी छोटी होनी चाहिए।

— दीमा

Answer 4

खराब प्रोग्रामर निरपेक्षता (सिथ की तरह) में बोलते हैं। अच्छे प्रोग्रामर स्पष्ट समाधान संभव का उपयोग करते हैं ( अन्य सभी चीजें समान हैं )।

ब्रेक का उपयोग और जारी रखने के लिए अक्सर कोड का पालन करना कठिन होता है। लेकिन अगर उन्हें प्रतिस्थापित करने से कोड का पालन करना कठिन हो जाता है, तो यह एक बुरा बदलाव है।

आपके द्वारा दिया गया उदाहरण निश्चित रूप से एक ऐसी स्थिति है जहां विराम और जारी रहना कुछ अधिक सुरुचिपूर्ण के साथ प्रतिस्थापित किया जाना चाहिए।

Comments

हाँ, मैंने मामलों की संख्या को बाहर निकलने के उदाहरण प्रदान करने के लिए स्थितियों की संख्या को बढ़ा दिया।

— मिखाइल

आपके द्वारा सुझाए गए प्रतिस्थापन कोड का एक उदाहरण क्या है? मैंने सोचा कि यह गार्ड के बयानों का एक उचित उदाहरण था।

— simgineer

यह मुझे लगता है कि "सबसे स्पष्ट समाधान संभव है" हमेशा ... संभव है? कैसे एक "स्पष्ट" समाधान नहीं हो सकता है? लेकिन फिर, मैं निरपेक्षता के लिए एक नहीं हूं, इसलिए शायद आप सही हैं।

@nocomprende मुझे यकीन नहीं है कि आप क्या कर रहे हैं। यहां "संभव" इंगित नहीं करता है कि सबसे अच्छा समाधान मौजूद नहीं है - केवल सही, अंतिम स्पष्टता कोई चीज नहीं है। यह व्यक्तिपरक है, सब के बाद।

— मैथ्यू पढ़ें

Answer 5

अधिकांश लोग सोचते हैं कि यह एक बुरा विचार है क्योंकि व्यवहार आसानी से अनुमानित नहीं है। यदि आप कोड के माध्यम से पढ़ रहे हैं और आप देखते while(x < 1000){}हैं कि आप इसे x> = 1000 तक चलाने जा रहे हैं ... लेकिन अगर बीच में ब्रेक होते हैं, तो यह सच नहीं है, इसलिए आप वास्तव में अपने पर भरोसा नहीं कर सकते पाशन ...

यही कारण है कि लोग GOTO को पसंद नहीं करते हैं: निश्चित रूप से, इसका उपयोग अच्छी तरह से किया जा सकता है, लेकिन यह ईश्वरीय स्फैगेटी कोड को भी जन्म दे सकता है, जहां कोड अनुभाग से अनुभाग तक यादृच्छिक रूप से लीक होता है।

खुद के लिए, अगर मैं एक लूप करने जा रहा था जो एक से अधिक शर्तों पर टूट गया था, तो मैं while(x){}तब एक्स को झूठा करने के लिए करूँगा जब मुझे बाहर तोड़ने की ज़रूरत थी। अंतिम परिणाम समान होगा, और कोड के माध्यम से पढ़ने वाले किसी भी व्यक्ति को एक्स के मूल्य को बदलने वाली चीजों पर अधिक बारीकी से देखना होगा।

Comments

+1 बहुत अच्छी तरह से कहा, और +1 (अगर मैं एक और कर सकता था) while(notDone){ }दृष्टिकोण के लिए।

— FrustratedWithFormsDesigner

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

— S.Lott

S.Lott ने नाखून को सिर पर चौकोर मारा। अभिव्यक्ति जो नियंत्रण को नियंत्रित करती है, उसमें हर वह शर्त शामिल होनी चाहिए जो पुनरावृति जारी रखने के लिए पूरी होनी चाहिए।

— बिट-ट्विडलर

के break;साथ प्रतिस्थापित x=false;करने से आपका कोड अधिक स्पष्ट नहीं हो जाता है। आपको अभी भी उस कथन के लिए शरीर को खोजना है। और आप के मामले में x=false;यह जाँचना होगा कि यह x=true;और नीचे नहीं गिरा है।

— सोजेरड

जब लोग कहते हैं कि "मैं एक्स देखता हूं और मैं वाई मानता हूं, लेकिन अगर आप जेड करते हैं तो यह धारणा पकड़ नहीं पाती है कि" मैं ऐसा सोचता हूं "तो वह मूर्खतापूर्ण धारणा नहीं बनाते हैं"। बहुत से लोग यह कहते हैं कि "जब मैं देखूंगा तो while (x < 1000)यह मान लूंगा कि यह 1000 बार चलेगा"। ठीक है, कई कारण हैं कि क्यों झूठा है, भले ही xशुरू में शून्य हो। उदाहरण के लिए, कौन कहता xहै कि लूप के दौरान एक बार ठीक-ठीक वृद्धि होती है, और कभी किसी अन्य तरीके से संशोधित नहीं होती है? यहां तक ​​कि अपनी खुद की धारणा के लिए, सिर्फ इसलिए कि कुछ सेट का x >= 1000मतलब यह नहीं है कि लूप समाप्त हो जाएगा - यह स्थिति की जांच होने से पहले वापस सीमा में सेट किया जा सकता है।

— स्टीव

Answer 6

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

एक कंप्यूटर विज्ञान का परिणाम है, जिसे कोसाराजू के नियंत्रण संरचनाओं का पदानुक्रम कहा जाता है, जो 1973 तक वापस आता है और जिसका उल्लेख 1974 से गोटो पर प्रसिद्ध कागज (अधिक) में किया गया है। (नथ का यह पेपर डेविड कॉर्नली द्वारा ऊपर पहले से ही सिफारिश किया गया था, वैसे ।) क्या एस राव कोसराजू 1973 में साबित कर दिया है कि यह सभी कार्यक्रमों है कि गहराई से बहु स्तरीय टूट जाता है के पुनर्लेखन के लिए संभव नहीं है है n तोड़ गहराई से भी कम समय के साथ कार्यक्रमों में n अतिरिक्त चर शुरू करने के बिना। लेकिन मान लीजिए कि यह केवल एक विशुद्ध सैद्धांतिक परिणाम है। (बस कुछ अतिरिक्त चर जोड़ें? निश्चित रूप से आप अपने मालिक को खुश करने के लिए ऐसा कर सकते हैं ...)

सॉफ्टवेयर इंजीनियरिंग के नजरिए से क्या अधिक महत्वपूर्ण है, एरिक एस। रॉबर्ट्स द्वारा लूप एग्जिट्स एंड स्ट्रक्चर्ड प्रोग्रामिंग: द रिओपनिंग द डिबेट ( http://cs.stanford.edu/people/eroberts -papers/SIGCSE-) शीर्षक से हाल ही में एक और अधिक महत्वपूर्ण है। 1995 / LoopExits.pdf )। रॉबर्ट्स उनके समक्ष दूसरों द्वारा किए गए कई अनुभवजन्य अध्ययनों का सारांश प्रस्तुत करते हैं। उदाहरण के लिए, जब CS101-प्रकार के छात्रों के एक समूह को एक सरणी में अनुक्रमिक खोज को लागू करने वाले फ़ंक्शन के लिए कोड लिखने के लिए कहा गया था, तो अध्ययन के लेखक ने कहा कि उन छात्रों के बारे में जो बाहर निकलने के लिए ब्रेक / रिटर्न / गोटो का उपयोग करते थे। तत्व मिलने पर अनुक्रमिक खोज लूप:

मुझे अभी तक एक भी व्यक्ति नहीं मिला है, जिसने [इस शैली] का उपयोग करके एक कार्यक्रम का प्रयास किया, जिसने एक गलत समाधान का उत्पादन किया।

रॉबर्ट्स यह भी कहते हैं कि:

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

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

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

Comments

हालांकि संरचित प्रोग्रामिंग कई वर्षों से मेरा दृष्टिकोण था, पिछले कुछ में पहले संभव अवसर पर पूरी तरह से स्पष्ट निकास का उपयोग करने के लिए स्विच किया गया है। यह तेजी से निष्पादन करता है और तर्क की त्रुटियों को लगभग समाप्त कर देता है जिसके परिणामस्वरूप अंतहीन लूप (फांसी) होते थे।

— DocSalvager

Answer 7

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

Comments

:) हाँ, मैंने जो उदाहरण दिया वह वैचारिक था

— मिखाइल

Answer 8

आपके द्वारा दिए गए उदाहरण को ब्रेक की आवश्यकता नहीं है और न ही जारी है:

while (primary-condition AND
       loop-count <= 1000 AND
       time-exec <= 3600) {
   when (data != "undefined" AND
           NOT skip)
      do-something-useful;
   }

आपके उदाहरण में 4 लाइनों के साथ मेरी 'समस्या' यह है कि वे सभी समान स्तर पर हैं, लेकिन वे अलग-अलग काम करते हैं: कुछ टूटते हैं, कुछ जारी रहते हैं ... आपको प्रत्येक पंक्ति को पढ़ना होगा।

मेरे नेस्टेड दृष्टिकोण में, आप जितने गहरे जाएंगे, उतना ही अधिक 'उपयोगी' कोड बनता जाएगा।

लेकिन, अगर गहरे अंदर आपको पाश (प्राथमिक-स्थिति के अलावा) को रोकने का कारण मिलेगा, तो ब्रेक या रिटर्न का उपयोग होगा। मुझे लगता है कि एक अतिरिक्त ध्वज के उपयोग से अधिक शीर्ष स्तर की स्थिति में परीक्षण किया जाना है। ब्रेक / रिटर्न अधिक प्रत्यक्ष है; यह बेहतर है कि किसी अन्य चर को सेट करने की तुलना में इरादा बेहतर हो।

Comments

+1 लेकिन वास्तव में आपकी <तुलना <=ओपी समाधान

— एल रोनोको

ज्यादातर मामलों में, यदि कोई इतना गहरा है कि प्रवाह नियंत्रण का प्रबंधन करने के लिए किसी को ब्रेक / रिटर्न का उपयोग करना है, तो किसी का कार्य / तरीका बहुत जटिल है।

— बिट-ट्विडलर

Answer 9

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

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

Comments

मैं दोनों बिंदुओं से सहमत हूँ! जहाँ तक आपका दूसरा बिंदु है - मुझे लगता है कि मेरे मूल पोस्ट का अनुसरण करना आसान है क्योंकि यह अंग्रेजी की तरह ही पढ़ता है। यदि आपके पास 1 स्टेटमेंट में स्टेटमेंट्स का संयोजन है, तो यह पता लगाने के लिए लगभग सही है कि क्या सच में निष्पादित करना है।

— मिखाइल

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

— जोएल एथर्टन

Answer 10

बिल्कुल नहीं ... हाँ का उपयोग gotoबुरा है क्योंकि यह आपके कार्यक्रम की संरचना को बिगड़ता है और नियंत्रण प्रवाह को समझना भी बहुत मुश्किल है।

लेकिन इन दिनों कथनों का उपयोग breakऔर continueबिल्कुल आवश्यक है और इन्हें बिल्कुल भी बुरा नहीं माना जाता है।

और यह भी मुश्किल नहीं है कि उपयोग में नियंत्रण प्रवाह को समझने के लिए breakऔर continue। जैसे निर्माणों में बयान बिल्कुल जरूरी है।switchbreak

Comments

मैंने 1981 में C को पहली बार सीखने के बाद से "जारी" का उपयोग नहीं किया है। यह एक अनावश्यक भाषा सुविधा है, क्योंकि जारी बयान द्वारा बाईपास किए गए कोड को सशर्त नियंत्रण कथन द्वारा लपेटा जा सकता है।

— बिट-टिडलर

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

— jsternberg

जीत के लिए @jsternberg! :-)

— नोटिफ़ल

Answer 11

आवश्यक धारणा आपके कार्यक्रम के शब्दार्थ का विश्लेषण करने में सक्षम होने से आती है। यदि आपके पास एक एकल प्रविष्टि और एक एकल निकास है, तो संभावित राज्यों को निरूपित करने के लिए आवश्यक गणित की तुलना में काफी आसान है यदि आपको रास्तों का प्रबंधन करना है।

भाग में, यह कठिनाई आपके कोड के बारे में वैचारिक रूप से सक्षम होने में दर्शाती है।

सच कहूं, तो आपका दूसरा कोड स्पष्ट नहीं है। यह क्या कर रहा हैं? क्या यह 'जारी' है, या यह 'अगले' लूप है? मुझे पता नहीं है। कम से कम आपका पहला उदाहरण स्पष्ट है।

Comments

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

— umlcat

आपकी "फ्रेंकली" टिप्पणी वाक्यगत है - "अगला" एक गलत बात है; सामान्य भाषा में "जारी रखें" का अर्थ है "इस पाश को छोड़ें"

— मिखाइल

@ मिक, शायद "इस पुनरावृत्ति को छोड़ दें" एक बेहतर वर्णन होगा। आपका सही मायने में, डॉ। आईएम पेडिक

— पीट विल्सन

@ मिखाइल: ज़रूर। लेकिन जब कोई बहुत सारी भाषाओं में काम करता है, तो यह त्रुटियों को जन्म दे सकता है जब भाषाओं के बीच वाक्यविन्यास आम नहीं होता है।

— पॉल नाथन

लेकिन गणित प्रोग्रामिंग नहीं है। गणित की तुलना में कोड अधिक अभिव्यंजक है। मुझे लगता है कि सिंगल-एंट्री / सिंगल-एग्जिट फ्लोचार्ट को अच्छे लग सकते हैं लेकिन किस कीमत पर (यानी जहां ब्रेक / रिटर्न कोड को बेहतर बना सकते हैं)?

— इवान प्लाइस

Answer 12

मैं आपके दूसरे कोड स्निपेट को बदल दूंगा

while (primary_condition && (loop_count <= 1000 && time_exect <= 3600)) {
    if (this->data != "undefined" && this->skip != true) {
        ..
    }
}

थकाऊ के किसी भी कारण के लिए नहीं - मुझे वास्तव में लगता है कि यह पढ़ना आसान है और किसी के लिए यह समझना आसान है कि क्या हो रहा है। आम तौर पर आपके छोरों के लिए शर्तों को बोलना विशुद्ध रूप से उन पाश स्थितियों के भीतर निहित होना चाहिए जो पूरे शरीर में नहीं होती हैं। हालांकि कुछ स्थितियों में, जहां देखते हैं breakऔर continueपठनीयता कर सकते हैं। मेरी breakतुलना में मोरेसो continueजोड़ सकता है: डी

Comments

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

— इवान प्लाइस

@ इवन स्थिति foreachलूप पर लागू नहीं है क्योंकि यह एक संग्रह में हर आइटम को पुन: व्यवस्थित करेगा। एक forलूप समान है कि इसमें सशर्त अंत बिंदु नहीं होना चाहिए। यदि आपको एक सशर्त अंत बिंदु की आवश्यकता है तो आपको एक whileलूप का उपयोग करने की आवश्यकता है ।

— एल रोनोको

@ इवान मैं आपकी बात देख सकता हूँ - 'लेकिन क्या होगा अगर आपको फ़ॉरन लूप से बाहर निकलने की ज़रूरत है?' - ठीक है, breakलूप से मेरी राय में केवल एक अधिकतम होना चाहिए ।

— एल रोन्नोको

Answer 13

मैं आपके बॉस से असहमत हूं। के लिए उचित स्थान नहीं हैं breakऔर continueप्रयोग की जाने वाली। वास्तव में यही कारण है कि आधुनिक प्रोग्रामिंग भाषाओं के लिए अपवाद और अपवाद हैंडलिंग को पेश किया गया है, ताकि आप केवल उपयोग करके हर समस्या को हल न कर सकें structured techniques।

एक साइड नोट पर मैं यहां एक धार्मिक चर्चा शुरू नहीं करना चाहता, लेकिन आप अपने कोड को इस तरह और भी पठनीय बनाने के लिए पुनर्गठन कर सकते हैं:

while (primary_condition) {
    if (loop_count > 1000) || (time_exect > 3600) {
        break;
    } else if ( ( this->data != "undefined") && ( !this->skip ) ) {
       ... // where the real work of the loop happens
    }
}

दूसरी तरफ ध्यान दें

मैं व्यक्तिगत रूप ( flag == true )से सशर्त के उपयोग को नापसंद करता हूं क्योंकि यदि चर पहले से ही एक बूलियन है, तो आप एक अतिरिक्त तुलना पेश कर रहे हैं, जब बूलियन के मूल्य का जवाब आप चाहते हैं, तब तक होना चाहिए - जब तक कि आप निश्चित नहीं हैं कि आपका कंपाइलर कि अतिरिक्त तुलना दूर अनुकूलन।

Comments

मैंने सालों से इस सवाल पर कमर कस ली है। आपका तरीका ('अगर (झंडा) {...}') बहुत अधिक प्रचलित है और शायद यह अधिक 'पेशेवर' या 'विशेषज्ञ' लगता है। लेकिन, हां 'पता है, इसका मतलब अक्सर यह होता है कि एक पाठक / अनुचर को खुद को संक्षिप्त रूप से याद करना पड़ता है कि निर्माण का क्या मतलब है; और परीक्षण की भावना के बारे में सुनिश्चित हो। वर्तमान में, मैं 'if (flag == true) {...}' का उपयोग सिर्फ इसलिए कर रहा हूं क्योंकि यह बेहतर प्रलेखन लगता है। अगले महीने? Quien sabe?

— पीट विल्सन

@Pete - शब्द नहीं है संक्षिप्त लेकिन सुरुचिपूर्ण । आप सभी आप चाहते हैं वफ़ल सकते हैं, लेकिन यदि आप चिंतित हैं कि पाठक / मेंटेनर नहीं समझती क्या एक कर रहे हैं booleanहै या क्या संक्षिप्त / सुरुचिपूर्ण शब्दावली का मतलब तो है हो सकता है आप बेहतर कुछ होशियार देखरेख ;-) किराया

— Zeke Hansell

@Pete, मैं जनरेट किए गए कोड के बारे में अपने बयान के साथ खड़ा हूं। आप अभिव्यक्ति के बूलियन मूल्य का मूल्यांकन करने से पहले एक निरंतर मूल्य के लिए एक ध्वज की तुलना करके एक और तुलना कर रहे हैं। इसे जितना कठिन होना है उससे अधिक कठिन क्यों है, ध्वज चर में पहले से ही वह मूल्य है जो आप चाहते हैं!

— ज़ेके हेन्सल

+1 अच्छा काम। निश्चित रूप से पूर्व उदाहरण की तुलना में बहुत अधिक सुरुचिपूर्ण।

— इवान प्लाइस

Answer 14

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

"ब्रेक" के लिए लूप को एक अलग विधि में निकालें, "ब्रेक" को "रिटर्न" से बदल दें।

यदि निकाले गए तरीकों में बड़ी संख्या में तर्कों की आवश्यकता होती है, तो यह एक वर्ग निकालने का एक संकेत है - या तो उन्हें एक संदर्भ वस्तु में इकट्ठा करें।

Answer 15

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

Comments

वास्तव में, यह देखना आसान है कि क्या आप ठीक से इंडेंट करते हैं, उन बयानों के शब्दार्थों को आंतरिक रूप दिया गया है और बहुत नींद नहीं आ रही है।

@ देलनान - यह बहुत सारी धारणाएं हैं;)

— दाविदस्किंस

हाँ, विशेष रूप से अंतिम।

— माइकल के

वैसे, गंभीर प्रोग्रामिंग के लिए # 1 आवश्यक है, # 2 प्रोग्रामर कहे जाने वाले सभी से अपेक्षित है, और # 3 सामान्य रूप से उपयोगी है;)

कुछ भाषाएं (केवल स्क्रिप्टिंग जो मुझे पता है) समर्थन break 2; दूसरों के लिए, मुझे लगता है कि अस्थायी बूल झंडे का उपयोग किया जाता है

— मिखाइल

Answer 16

जब तक वे निम्न उदाहरण में प्रच्छन्न गोटो के रूप में उपयोग नहीं किए जाते हैं:

do
{
      if (foo)
      {
             /*** code ***/
             break;
      }

      if (bar)
      {
             /*** code ***/
             break;
      }
} while (0);

मैं उनके साथ ठीक हूं। (उदाहरण उत्पादन कोड में देखा, meh)

Comments

क्या आप कार्यों को बनाने के लिए इस तरह के मामलों की सिफारिश करेंगे?

— मिखाइल

हाँ और यदि संभव न हो तो एक सादा गोटो। जब मुझे कोई काम दिखता है, तो मैं दोहराव के बारे में सोचता हूं, न कि छलांग का अनुकरण करने के लिए।

— SuperBloup

ओह मैं सहमत हूं, मैं सिर्फ यह पूछ रहा था कि आप इसे कैसे करेंगे :) कंप्यूटर वैज्ञानिक इसे बार

— मिखाइल

Answer 17

मुझे इनमें से कोई भी स्टाइल पसंद नहीं है। यहाँ मैं क्या पसंद करेंगे:

function verify(object)
{
    if not (object->value < 0) 
       and not(object->value > object->max_value)
       and not(object->name == "") 
       {
         do somethign important
       }
    else return false; //probably not necessary since this function doesn't even seem to be defined to return anything...?
}

मैं वास्तव में returnएक समारोह को खत्म करने का उपयोग करना पसंद नहीं करता। यह एक दुरुपयोग की तरह लगता है return।

उपयोग करना breakभी हमेशा पढ़ने के लिए स्पष्ट नहीं होता है।

बेहतर अभी तक हो सकता है:

notdone := primarycondition    
while (notDone)
{
    if (loop_count > 1000) or (time_exect > 3600)
    {
       notDone := false; 
    }
    else
    { 
        skipCurrentIteration := (this->data == "undefined") or (this->skip == true) 

        if not skipCurrentIteration
        {
           do something
        } 
        ...
    }
}

कम घोंसले के शिकार और जटिल परिस्थितियों को चर में बदल दिया जाता है (एक वास्तविक कार्यक्रम में आपके पास बेहतर नाम होना चाहिए, जाहिर है ...)

(सभी उपरोक्त कोड छद्म कोड है)

Comments

आप वास्तव में ऊपर टाइप किए गए घोंसले के 3 स्तरों को पसंद करेंगे?

— मिखाइल

@ मिखाइल: हां, या मैं एक चर के लिए स्थिति का परिणाम बताऊंगा। मैं इसे बहुत आसान के तर्क से समझने के लिए लगता है breakऔर continue। असामान्य रूप से एक लूप को समाप्त करना अजीब लगता है और मुझे यह पसंद नहीं है।

— FrustratedWithFormsDesigner

विडंबना यह है कि आपने मेरी शर्तों को गलत बताया है। continueइसका मतलब है कि कार्यक्षमता को अगले लूप पर जाएं; "निष्पादन के साथ जारी नहीं"

— मिखाइल

@ मिखाइल: आह। मैं अक्सर इसका उपयोग नहीं करता हूं और जब मैं इसे पढ़ता हूं, तो मैं अर्थ से भ्रमित हो जाता हूं। एक और कारण मुझे यह पसंद नहीं है। : P मुझे अपडेट करने के लिए एक मिनट दें ...

— FrustratedWithFormsDesigner

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

— Zeke Hansell

Answer 18

नहीं। यह एक समस्या को हल करने का एक तरीका है, और इसे हल करने के अन्य तरीके हैं।

कई वर्तमान मुख्यधारा की भाषाएँ (जावा, .NET (C # + VB), PHP, अपना खुद का लिखना) "ब्रेक" का उपयोग करें और लूप्स को छोड़ने के लिए "जारी रखें"। वे दोनों "संरचित गोटो (ओं)" वाक्य हैं।

उनके बिना:

String myKey = "mars";

int i = 0; bool found = false;
while ((i < MyList.Count) && (not found)) {
  found = (MyList[i].key == myKey);
  i++;   
}
if (found)
  ShowMessage("Key is " + i.toString());
else
  ShowMessage("Not found.");

उनके साथ:

String myKey = "mars";

for (i = 0; i < MyList.Count; i++) {
  if (MyList[i].key == myKey)
    break;
}
ShowMessage("Key is " + i.toString());

ध्यान दें कि, "ब्रेक" और "जारी रखें" कोड छोटा है, और आमतौर पर "के लिए" "या" के लिए "वाक्यों" वाक्यों में बदल जाता है।

दोनों ही मामले कोडिंग स्टाइल का मामला हैं। मैं उनका उपयोग नहीं करना पसंद करता हूं , क्योंकि क्रिया शैली मुझे कोड का अधिक नियंत्रण रखने की अनुमति देती है।

मैं वास्तव में, कुछ परियोजनाओं में काम करता हूं, जहां उन वाक्यों का उपयोग करना अनिवार्य था।

कुछ डेवलपर्स यह सोच सकते हैं कि वे नोल्डेरिल्ली नहीं हैं, लेकिन काल्पनिक हैं, अगर हमें उन्हें निकालना था, तो हमें "जबकि" और "करते हुए" ("फिर से दोहराएं", आपको पास्कल करना होगा) ;-)

निष्कर्ष, भले ही मैं उनका उपयोग न करना पसंद करता हूं, मुझे लगता है कि इसका विकल्प है, न कि खराब प्रोग्रामिंग अभ्यास।

Comments

Picky होने के लिए क्षमा करें, लेकिन कुंजी नहीं मिलने पर आपका दूसरा उदाहरण आउटपुट याद कर रहा है (इसलिए निश्चित रूप से यह बहुत छोटा दिखता है)।

— FrustratedWithFormsDesigner

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

— मिखाइल

@FrustratedWithFormsDesigner वास्तव में। मैं purpouse पर डाल दिया कि क्यों बेहतर है कि विधि

— ;;

हालाँकि, आपके पास अलग-अलग शब्दार्थ के साथ दो रूटीन हैं; इसलिए, वे तार्किक रूप से समकक्ष नहीं हैं।

— बिट-टिडलर

आपके दूसरे उदाहरण में दो बग हैं, एक वाक्यात्मक और एक तार्किक। 1. यह संकलित नहीं करेगा क्योंकि इट्रेटर को लूप के दायरे से बाहर घोषित नहीं किया गया है (इसलिए स्ट्रिंग आउटपुट में उपलब्ध नहीं है)। 2. अगर लूप के बाहर भी इटरेटर घोषित किया गया था, अगर संग्रह में कुंजी नहीं मिली है, तो स्ट्रिंग आउटपुट सूची में अंतिम आइटम की कुंजी प्रिंट करेगा।

— इवान प्लाइस

Answer 19

मैं खिलाफ नहीं हूं continueऔर breakसिद्धांत रूप में, लेकिन मुझे लगता है कि वे बहुत ही निम्न स्तर के निर्माण हैं जो बहुत बार कुछ बेहतर तरीके से प्रतिस्थापित किए जा सकते हैं।

मैं यहां एक उदाहरण के रूप में C # का उपयोग कर रहा हूं, एक संग्रह पर पुनरावृति चाहने के मामले पर विचार करें, लेकिन हम केवल उन तत्वों को चाहते हैं जो कुछ विधेय को पूरा करते हैं, और हम अधिकतम 100 पुनरावृत्तियों से अधिक नहीं करना चाहते हैं।

for (var i = 0; i < collection.Count; i++)
{
    if (!Predicate(item)) continue;
    if (i >= 100) break; // at first I used a > here which is a bug. another good thing about the more declarative style!

    DoStuff(item);
}

यह वास्तव में साफ दिखता है। इसे समझना बहुत कठिन नहीं है। मुझे लगता है कि यह अधिक घोषणात्मक होने से बहुत कुछ हासिल करने के लिए खड़ा होगा। इसकी तुलना निम्न से करें:

foreach (var item in collection.Where(Predicate).Take(100))
    DoStuff(item);

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

निम्न-स्तर का सामान अभी भी कोड के कुछ हिस्सों में मौजूद होगा, लेकिन हम इसे जितना संभव हो सके छुपाना चाहते हैं, क्योंकि यह मानसिक ऊर्जा लेता है जिसका उपयोग हम व्यावसायिक समस्याओं के कारण करने के लिए कर सकते हैं।

Answer 20

कोड पूरा का उपयोग करने gotoऔर दिनचर्या या पाश से कई रिटर्न के बारे में एक अच्छा खंड है ।

सामान्य तौर पर यह बुरा अभ्यास नहीं है। breakया continueबताएं कि आगे क्या होता है। और मैं इससे सहमत हूं।

स्टीव मैककोनेल (कोड कम्प्लीट के लेखक) लगभग उतने ही उदाहरणों का उपयोग करता है जितना कि आप विभिन्न gotoकथनों का उपयोग करने के फायदे दिखाने के लिए करते हैं ।

हालांकि अति प्रयोग breakया continueजटिल और अचूक सॉफ्टवेयर को जन्म दे सकता है।