लूप में स्थितियां, सर्वोत्तम प्रथाएं?

Question

मैं इस तरह एक पाश है कहते हैं:

for (int i = 0; i < someint; i++) 
{ 
    if (i == somecondition) 
    { 
     DoSomething(); 
     continue; 
    } 
    doSomeOtherStuff(); 
} 

बनाम ...

for (int i = 0; i < someint; i++) 
{ 
    if (i == somecondition) 
    { 
     DoSomething(); 
    } 
    else 
    { 
     doSomeOtherStuff(); 
    } 
} 

वहाँ एक दूसरे के ऊपर का उपयोग करने के किसी भी कारण है? या यह सिर्फ व्यक्तिगत वरीयता है?
मुख्य भाषा मैं जावा के लिए यह पूछ रहा हूं जावा है, लेकिन मुझे लगता है कि यह ज्यादातर अन्य लोगों पर भी लागू होता है।

Answer 1

तकनीकी रूप से, नहीं, लेकिन मुझे इस विशेष मामले के लिए दूसरा एक सुंदर लगता है।

Answer 2

मैं निश्चित रूप से दूसरा वाक्यविन्यास पसंद करूंगा।

जहां भी संभव हो जारी बयान से बचने का प्रयास करें। यह कोड पथ अधिक का पालन करने और वजह मुश्किल

Answer 3

मैं दूसरा निर्माण पसंद करते हैं डिबग करने के लिए कठिन बना देता है ...

for (int i = 0; i < someint; i++) 
{ 
    if (i == somecondition) 
    { 
     DoSomething(); 
     //lets say lot of code 
     //.. 
     //... 
     //... 
     //... 
     continue; 
    } 
    else 
    { 
     doSomeOtherStuff(); 
    } 
} 

कहते हैं कि तुम continue से पहले कोड के बहुत था देता है। यह सिर्फ देख

else 
    { 
     doSomeOtherStuff(); 
    } 

यह बिना शर्त निष्पादित नहीं है द्वारा तुरंत स्पष्ट है।

Answer 4

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

for (String tok : tokens) { 
    if (isKeyword(tok)) { 
     output.write(tok); 
     continue; 
    } 
    // Do some massive processing of non-keyword tokens here 
    // This block goes on... 
    // and on... 
    // and on... You get the idea 
} 

बनाम

for (String op : operators) { 
    if (isAdditive(op)) { 
     // Do something for additive ops 
    } else { 
     // Do something for non-additive ops 
    } 
} 

Answer 5

इस विशेष मामले में, मैं हर किसी की है कि दूसरी पसंद किया जाता है के साथ सहमत हैं। लेकिन ऐसे मामले हैं जहां मैं पहले के लिए जाऊंगा। यदि DoSomething() वास्तव में केवल एक कॉल था, और i == someCondition एक बढ़त मामला है, और doSomeOtherStuff() वास्तव में केवल एक कॉल के बजाय कोड की 20 पंक्तियां थीं, तो मैं continue का उपयोग करना पसंद करूंगा। उस परिदृश्य में, मैंने इसे "पहले" के रूप में पढ़ा है, आइए जल्दी ही इस किनारे के मामले का ख्याल रखें। ठीक है, अब असली चीजें करते हैं। "

बेशक, कोई भी मेरी व्याख्या को दोबारा करके if-else के लिए तर्क दे सकता है "अगर हम किनारे के मामले में हैं तो असली चीजें करें।" लेकिन इसका मतलब है कि उन सभी 20 लाइनें अब घोंसले की गहरी हैं, और मेरे लिए यह पहले किनारे के मामलों की देखभाल करने के लिए और अधिक पढ़ने योग्य है, और फिर सामान्य पथ पर ध्यान केंद्रित करें।

Answer 6

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

JSF ++ (नियम 190) और मिश्रा सी (नियम 57) कहते हैं कि:

बयान जारी रखने के लिए नहीं किया जाएगा

बस आप एक संदर्भ देने के लिए।

वे सुरक्षा-महत्वपूर्ण अनुप्रयोगों के मानकों हैं, लेकिन इन्हें अन्य ऐप्स पर भी लागू किया जा सकता है।

मिश्रा भुगतान किया जाता है, लेकिन JSF ++ मुक्त यहाँ डाउनलोड किया जा सकता:

http://www.jsf.mil/downloads/documents/JSF_AV_C++_Coding_Standards_Rev_C.doc

यह सी के लिए ++ है, लेकिन बहुत से नियम अन्य भाषाओं के लिए लागू किया जा सकता है। यह पढ़ने लायक है!

Answer 7

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

उदाहरण आप एक बहुत कुछ है के लिए कहो, और मैं मतलब जहां if बयान का एक बहुत होने से वास्तव में खरोज के माध्यम से पठनीयता को प्रभावित करता है अपने पाश, अंदर की स्थिति का एक बहुत:

for (int i = 0 ; i < n ; i++) 
{ 
    if (obj[i]) 
    { 
     doSomething(); 
     if (someOtherCondition() 
     { 
      //........... 
                if (/* some levels down */) 
                { 

                } 
      //..... 
     } 
    } 
} 

तर्क

मैं मिल सकता है जैसे कि "आप इसे दोबारा कर सकते हैं" ब्ला ब्लाह, लेकिन कभी-कभी, शायद ही कभी, आप बस नहीं कर सकते।

तो तुम refactor और यह एक बहुत अधिक पठनीय साथ बना सकते हैं:

for (int i = 0 ; i < n ; i++) 
{ 
    if (!obj[i]) 
    { 
     continue; 
    } 
    doSomething(); 
    if (!someOtherCondition() 
    { 
     continue; 
    } 
    //........... 
} 

Answer 8

मैं इसे आप क्या कर रहे के बारे में अधिक निर्भर करता है लगता है।

यह एक साधारण उदाहरण है, लेकिन एक नियम के रूप में यदि कोई शर्त है कि मैं अन्य लूप तर्क से "निकालने" कर रहा हूं, तो मैं इसे जटिलता में जोड़ने के बजाय जितनी जल्दी हो सके इसे बाहर खींचूंगा भविष्य अगर बयान (अपना पहला उदाहरण है अगर यह एक शर्त है कि भविष्य तर्क को सरल बनाने निकाला जा सकता है है) उदाहरण के लिए:

for (int i = 0 ; i < n ; i++) 
{ 
    if(obj[i] != null && obj[i].instanceOf("A")) { 
     doSomething(); 
    } else if(obj[i] != null && obj[i].instanceOf("B"){ 
     doSomethingElse(); 
    } 
} 

अब यह स्पष्ट है कि

if(obj[i] == null) { 
    continue; 
} 

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

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

for (int i = 0 ; i < n ; i++) 
{ 
    obj[i].doSomething(); 
}