2012-10-09 12 views
32

के अंत में जावा टिप्पणी क्या जावा प्रोग्रामिंग भाषा में एक कोड ब्लॉक के लिए एक ब्रेस समाप्त करने के लिए यह एक स्वीकार्य अभ्यास है जो संक्षेप में बताता है कि ब्रेस बंद करने वाले कोड को बंद कर दिया गया है? मैं व्यक्तिगत रूप से सोचता हूं कि वे बेकार टिप्पणियां हैं जो कोड की पठनीयता को अव्यवस्थित करती हैं, लेकिन शायद मैं गलत हो सकता हूं। उदाहरण के लिए:ब्रेस/ब्लॉक

public void myMethod(int foo) {  
    // some code 
    if (foo == 2) { 
     for (int i = 0; i < myMax; i++) { 
      while (true) { 
       // some more code 
      } // end while 
     } // end for 
    } // end if 
} // end myMethod(int) 

क्या कोड ब्लॉक को एक स्वीकार्य अभ्यास में टिप्पणी करने का अभ्यास है?

+3

तक इंतजार आप कई भीतरी ब्लॉक है, लाइनों के 10 के या यहां तक ​​कि 100 के से अलग ... तो यह मदद करता है। इस बारे में सोचें कि यह कैसा दिखता है यदि आपके पास लूप के भीतर कुछ अन्य 'if' कथन हैं ... – MadProgrammer

+32

यदि आपके पास ब्लॉक के भीतर 100 लाइनें हैं तो आपको शायद वहां से एक विधि खींचने और सब कुछ आसान बनाने पर विचार करना चाहिए। – digitaljoel

+0

मुझे व्यक्तिगत रूप से लगता है कि उचित टिप्पणियों के साथ ब्रेस ब्लॉक को समाप्त करने के लिए यह अच्छा अभ्यास है। यह मेरे कोड को स्कॉप्स के बारे में भ्रम की कम से कम संभावना के साथ और अधिक समझने योग्य बनाता है। – exexzian

उत्तर

38

यह वास्तव में एक बुरा अभ्यास नहीं है, लेकिन यह खराब ऑब्जेक्ट-ओरिएंटेड कोडिंग अभ्यास के घातक दुष्प्रभाव है!

इसके अलावा, यह शैली दिशानिर्देशों और "self-documenting code" के सिद्धांतों का उल्लंघन करता है। आपके पास ब्रैकेट प्लेसमेंट के बारे में पाठक को भ्रमित करने के लिए पर्याप्त रूप से इतने सारे ब्रैकेट या विधि नहीं होनी चाहिए, इसके बजाय अच्छी तरह से प्रलेखित की गई किसी अन्य विधि में कार्यक्षमता को समाहित करना चाहिए।

ब्रैकेट्स या तो लूपिंग या कॉम्प्लेक्स को इंगित करते हैं - अन्यथा तर्क श्रृंखला, अच्छी प्रोग्रामिंग अभ्यास एक विधि है जो वास्तव में एक चीज करता है और इसे अच्छी तरह से करता है, फिर इन छोटे, परमाणु तरीकों से अपना प्रोग्राम बनाएं। मैं बटलर लैम्पसन के मौलिक टुकड़े "Hints for Computer System Design" पढ़ूंगा। यह अच्छे सॉफ्टवेयर को डिजाइन करने के तरीके के बारे में कुछ विवरणों में जाता है।

तो अनिवार्य रूप से, इस तरह क्योंकि टिप्पणी नहीं करते:

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

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

+0

मैं असहमत हूं, कोड को इसके बजाय दोबारा प्रतिक्रिया दी जानी चाहिए। – Matsemann

58

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

यह एक अच्छा अभ्यास है जब आप बंद करने से एक है और इसके विपरीत पर कर्सर रखें क्योंकि

  1. आधुनिक संपादकों प्रारंभ कोष्ठक उजागर नहीं है।
  2. सबसे महत्वपूर्ण: यदि खंड की शुरुआत को देखने की कोई संभावना नहीं है तो इसका मतलब है कि विधि बहुत बड़ी है (आधे पृष्ठ से अधिक) जो एक खराब प्रथा है।
  3. यह कोड को शोर जोड़ता है जो पाठकों को भ्रमित करेगा जो अधिक पारंपरिक जावा कोडिंग शैली में उपयोग किए जाते हैं।
  4. लॉर्डस्की-जोआचिम सॉर टिप्पणी शामिल: ये टिप्पणियां बनाए रखने के लिए गर्दन में दर्द हो सकती हैं। इसलिए सबसे अधिक संभावना है कि इसे बनाए रखा नहीं जाएगा और जानकारी आम तौर पर वास्तविकता के साथ सिंक हो जाएगी।
+5

+1: 4. यह – LordScree

+7

@LordScree को बनाए रखने के लिए ** में दर्द होगा: या यहां तक ​​कि अनुशासनिक: "4. यह बनाए रखा नहीं जाएगा और जानकारी आमतौर पर वास्तविकता के साथ सिंक हो जाएगी" –

+0

ग्रहण, उदाहरण के लिए, ब्लॉक की जानकारी प्रदर्शित करता है, यदि आप माउस कर्सर को बंद ब्रैकेट पर रखते हैं। –

0

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

0

आईएमओ, यह बहुत मदद नहीं करता है। लूप या एक कथन के अंदर कोड बहुत बड़ा नहीं होना चाहिए। यदि लूप के अंदर 500 लाइनें हों तो इससे मदद मिलेगी।

1

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

कोई चीज जो इस तरह दिखता है:

 
      // ... 
      file.Close(); 
      } 
     } 
     } 
    } 
    } 
} 

तो यह कुछ टिप्पणी जोड़ने में मदद करता है:

 
      // ... 
      file.Close(); 
      } 
     } 
     } 
    }//for: each file 
    } 
}