जावास्क्रिप्ट में "जारी रखें" बयान क्यों खराब हैं?

Question

पुस्तक जावास्क्रिप्ट में

: अच्छी पार्ट्स डगलस Crockford द्वारा, यह सब लेखक जारी रखने के वक्तव्य के बारे में क्या कहना है है:

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

यह वास्तव में मुझे भ्रमित करता है। मुझे पता है कि क्रॉकफोर्ड के पास जावास्क्रिप्ट पर कुछ बहुत ही विचार किए गए विचार हैं, लेकिन यह सिर्फ मेरे लिए पूरी तरह से गलत लगता है।

सबसे पहले, continue बस एक लूप के शीर्ष पर कूदने से कहीं अधिक है। डिफ़ॉल्ट रूप से, यह अगले पुनरावृत्ति में भी प्रगति करता है। तो क्रॉकफोर्ड का बयान सिर्फ पूरी तरह झूठी सूचना नहीं है?

अधिक महत्वपूर्ण बात यह है कि, मुझे पूरी तरह से समझ में नहीं आता कि continue को भी बुरा माना जाएगा। Why is continue inside a loop a bad idea?

हालांकि मैं समझ कैसे continue कोड कुछ मामलों में पढ़ने के लिए कठिन बना सकती हैं, मुझे लगता है कि बस के रूप में होने की संभावना है कि यह कोड अधिक पठनीय बना सकते हैं: इस पोस्ट में क्या आम धारणा हो रहा है प्रदान करता है। उदाहरण के लिए:

var someArray=['blah',5,'stuff',7]; 
for(var i=0;i<someArray.length;i++){ 
    if(typeof someArray[i]==='number'){ 
     for(var j=0;j<someArray[i];j++){ 
      console.log(j); 
     } 
    } 
} 

यह पुनर्संशोधित किया जा सकता है में:

var someArray=['blah',5,'stuff',7]; 
for(var i=0;i<someArray.length;i++){ 
    if(typeof someArray[i]!=='number'){ 
     continue; 
    } 
    for(var j=0;j<someArray[i];j++){ 
     console.log(j); 
    } 
} 

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

क्रॉकफोर्ड कोई स्पष्टीकरण प्रदान नहीं करता है कि continue का उपयोग क्यों नहीं किया जाना चाहिए, तो क्या इस राय के पीछे कुछ गहरा महत्व है कि मुझे याद आ रही है?

Answer 1

कथन हास्यास्पद है। continue का दुरुपयोग किया जा सकता है, लेकिन यह अक्सर पठनीयता में मदद करता है।

विशिष्ट उपयोग:

for (somecondition) 
{ 
    if (!firsttest) continue; 

    some_provisional_work_that_is_almost_always_needed(); 

    if (!further_tests()) continue; 

    do_expensive_operation(); 
} 

लक्ष्य 'लज़ान्या' कोड है, जहां आप गहराई से नेस्टेड सशर्त है से बचना है। जोड़ने के लिए

संपादित:

हाँ, यह अंत में व्यक्तिपरक है। Here's my metric for deciding.

एक आखिरी बार संपादित:

यह उदाहरण भी सरल, निश्चित रूप से है, और आप हमेशा समारोह कॉल के साथ नेस्टेड सशर्त, बदल सकते हैं। लेकिन फिर आपको संदर्भ द्वारा नेस्टेड फ़ंक्शंस में डेटा पास करना पड़ सकता है, जो कम से कम उतना ही खराब हो सकता है जितना आप टालने का प्रयास कर रहे हैं।

Answer 2

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

Answer 3

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

Answer 4

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

लेकिन यहां तक ​​कि continue के साथ आपका उदाहरण भी मेरी राय में सुधार नहीं दिखाता है जो उचित है। मेरे अनुभव से कुछ continue स्टेटमेंट्स बाद में रिफैक्टर करने के लिए दुःस्वप्न हैं (यहां तक ​​कि स्थिर भाषाओं के लिए भी जावा जैसे स्वचालित रीफैक्टरिंग के लिए उपयुक्त है, खासकर जब कोई बाद में break डालता है)। अपने आगे refactor करने की क्षमता inreases continue बयान को दूर करने के

पुनर्रचना:

इस प्रकार, मैं बोली आप दे दी है के लिए एक टिप्पणी जोड़ना होगा।

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

यह एक टीम में जावास्क्रिप्ट परियोजनाओं पर व्यावसायिक रूप से काम करने के बाद मेरी ईमानदार राय है, वहां नियम है कि डगलस क्रॉकफोर्ड वास्तव में अपनी योग्यता दिखाने के बारे में बात करता है।

Answer 5

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

उदाहरण 1

while (rec = getrec()) 
{ 
    if (condition1(rec)) 
     continue; 

    doSomething(rec); 
} 

लेकिन, मेरा अनुमान है कि वह होगा की तरह कुछ लिखने:

उदाहरण 2

rec = getrec(); 

while (rec) 
{ 
    if (!condition(rec)) 
     doSomething(rec); 

    rec = getrec(); 
} 

दोनों इन कार्यों में से, लेकिन यदि आप गलती से इन सेंट मिश्रण करते हैं

उदाहरण 3

rec = getrec(); 

while (rec) 
{ 
    if (condition1(rec)) 
     continue; 

    rec = getrec(); 
} 

यही कारण है कि वह पसंद नहीं करता जारी है का हिस्सा हो सकता: yles आप अनंत लूप मिलता है।

Answer 6

वास्तव में, सभी विश्लेषण से ऐसा लगता है: - (? भी, वहाँ कुछ निष्पादन लाभ हो सकते)

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

डगलस Crokford के बचाव में, मुझे लगता है कि उसकी सिफारिशों defensive programming की ओर झुक कर, सभी ईमानदारी में 'बेवकूफ प्रूफ' उद्यम में कोड के लिए एक अच्छा दृष्टिकोण की तरह लगता है जो, करते हैं लग रहा है।