2008-08-19 8 views
18

कभी-कभी लेबल किए गए ब्रेक या जारी रखने से कोड बहुत अधिक पठनीय हो सकता है।जावा कोडिंग मानक/सर्वोत्तम प्रथाओं - ब्रेक/जारी रखने के लिए नामकरण सम्मेलन

OUTERLOOP: for (;/*stuff*/;) { 
    //...lots of code 

    if (isEnough()) break OUTERLOOP; 
    //...more code 
} 

मैं सोच रहा था कि लेबल के लिए आम सम्मेलन क्या था। सभी कैपिटल? पहली टोपी?

उत्तर

16

यदि आपको उनका उपयोग राजधानियों का उपयोग करना है, तो यह उनके लिए ध्यान आकर्षित करता है और उन्हें गलती से "कक्षा" नाम के रूप में व्याख्या करने से बाहर निकाल देता है। उन पर ध्यान आकर्षित करने से किसी की आंख को पकड़ने का अतिरिक्त लाभ होता है जो आपके कोड के साथ आ जाएगा और उन्हें हटा देगा और उन्हें हटा देगा। ;)

15

सम्मेलन लेबल से पूरी तरह से बचने के लिए है।

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

for (;/*stuff*/;) 
{ 
    lotsOfCode(); 

    if (!isEnough()) 
    { 
     moreCode(); 
    } 
} 

संपादित करें: सवाल (over here) में वास्तविक कोड भी देखा है, मुझे लगता है कि लेबल का उपयोग शायद कोड पठनीय बनाने के लिए सबसे अच्छा तरीका है। अधिकांश मामलों में लेबल का उपयोग गलत दृष्टिकोण है, इस उदाहरण में, मुझे लगता है कि यह ठीक है।

0

रूपांतरण/सर्वोत्तम अभ्यास अभी भी उनका उपयोग नहीं करेगा और कोड को दोबारा उपयोग करने के लिए होगा ताकि विधि के रूप में निकालने का उपयोग करके अधिक पठनीय हो।

0

वे जावा के गेटो के प्रकार हैं - सुनिश्चित नहीं हैं कि सी # में उनका क्या है। मैंने कभी अभ्यास में उनका उपयोग नहीं किया है, मैं ऐसे मामले के बारे में नहीं सोच सकता जहां उन्हें टालने से ज्यादा पठनीय कोड न हो।

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

1

मुझे पता है, मुझे लेबल का उपयोग नहीं करना चाहिए।

लेकिन मान लीजिए, मेरे पास कुछ कोड है, जो लेबल किए गए ब्रेक से पठनीयता में बहुत कुछ हासिल कर सकता है, मैं उन्हें कैसे प्रारूपित कर सकता हूं।

मो, आपका आधार गलत है। सवाल यह नहीं होना चाहिए कि 'मैं उन्हें कैसे प्रारूपित करूं?'

आपका प्रश्न होना चाहिए 'मेरे पास कोड है जिसमें लूप के अंदर बड़ी मात्रा में तर्क है - मैं इसे और अधिक पठनीय कैसे बना सकता हूं?'

उस प्रश्न का उत्तर कोड को व्यक्तिगत, अच्छी तरह से नामित कार्यों में स्थानांतरित करना है। फिर आपको ब्रेक को लेबल करने की आवश्यकता नहीं है।

1

सम्मेलन मैं सबसे देखा है एक विधि नाम की तरह बस ऊंट मामला है, ...

myLabel: 

लेकिन मैं यह भी एक अंडरस्कोर

_myLabel: 

या साथ साथ उपसर्ग लेबल देखा है प्रयोगशाला ...

labSomething: 

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

33

मुझे समझ नहीं आता, जहां इस "लेबल का उपयोग नहीं करते" नियम से आता है। गैर-तुच्छ लूपिंग तर्क करते समय, ब्रेक या जारी रखने का परीक्षण आसपास के ब्लॉक के अंत में हमेशा साफ नहीं होता है।

outer_loop: 
for (...) { 
    // some code 
    for (...) { 
    // some code 
    if (...) 
     continue outer_loop; 
    // more code 
    } 
    // more code 
} 

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

for (...) { 
    // some code 
    boolean continueOuterLoop = false; 
    for (...) { 
    // some code 
    if (...) { 
     continueOuterLoop = true; 
     break; 
    } 
    // more code 
    } 
    if (continueOuterLoop) 
    continue; 
    // more code 
} 

यक! यह Refactoring के रूप में एक विधि है कि कम नहीं है या तो:

boolean innerLoop (...) { 
    for (...) { 
    // some code 
    if (...) { 
     return true; 
    } 
    // more code 
    } 
    return false; 
} 

for (...) { 
    // some code 
    if (innerLoop(...)) 
    continue; 
    // more code 
} 

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

तो आप सभी लेबल के खिलाफ क्यों हैं? मुझे उपरोक्त मामले के लिए कुछ ठोस कारण, और व्यावहारिक विकल्प दें।

+10

* चार साल बाद अद्यतन: * स्काला और Clojure जिसमें सलाह लेबल का उपयोग नहीं करने के लिए अच्छे कारण के लिए मान्य है की तरह कार्यात्मक भाषाओं की दिशा में एक वृद्धि की प्रवृत्ति नहीं है। लेकिन सामान्य जावा के लिए, ऊपर मेरा जवाब अभी भी खड़ा है। –

+0

और जावास्क्रिप्ट के साथ-साथ किसी भी घटना आधारित भाषा। इस प्रकार सेम के लिए यह इतना उपयोगी नहीं हो सकता है, जब तक कि यह कुछ बहुत (शायद भी) लंबी घटना प्रबंधन का हिस्सा नहीं था। – Cheruvim

+0

उत्सुक है कि शीर्ष वोट वाले उत्तर मूल प्रश्न का उत्तर नहीं देते हैं। ("* मैं सोच रहा था कि लेबल के लिए आम सम्मेलन क्या था। सभी कैप्स? पहली टोपी? *") – Jonik

1

wrt sadie's code example:

आप एक उदाहरण के रूप

outerloop: 
for (...) { 
    // some code 
    for (...) { 
    // some code 
    if (...) 
     continue outerloop; 
    // more code 
    } 
    // more code 
} 

दे दी है। तुमने एक अच्छी बात कही। मेरा सबसे अच्छा अनुमान होगा:

public void lookMumNoLabels() { 
    for (...) { 
    // some code 
    doMoreInnerCodeLogic(...); 
    } 
} 

private void doMoreInnerCodeLogic(...) { 
    for (...) { 
     // some code 
     if (...) return; 
    } 
} 

लेकिन ऐसे उदाहरण होंगे जहां इस प्रकार का रिफैक्टरिंग जो भी तर्क आप कर रहे हैं उसके साथ सही ढंग से नहीं बैठता है।

1

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

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

और अगर वे सही उपकरण हैं, ताकि अन्य डेवलपर्स (या अपने आप को बाद में) अभी कुछ असामान्य रूप में उन्हें एहसास उन सब टोपियां बनाते हैं। (के रूप में क्रेग पहले ही बताया)

5

सूर्य की जावा कोड शैली चर के रूप में एक ही तरीके से नामकरण लेबल को पसंद करते हैं, लोअर केस में पहले अक्षर के साथ ऊंट मामले अर्थ लगते हैं।