कोड के अंत में "// ..." टिप्पणी के बाद - अच्छा या बुरा? [बन्द है]

Question

मैंने अक्सर देखा है कि ऐसी टिप्पणियों का उपयोग किया जाता है:

function foo() {
   ...
} // foo

while (...) {
   ...
} // while

if (...) {
   ...
} // if

और कभी-कभी जहाँ तक भी

if (condition) {
   ...
} // if (condition)

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

तो लोग इसका उपयोग क्यों करते हैं? क्या हमें इसका उपयोग करना चाहिए, या क्या यह बुरा अभ्यास है?

Comments

PHP में, मैं नियंत्रण संरचनाओं के लिए वैकल्पिक सिंटैक्स का उपयोग करता हूंif(condition): ... else: ... endif;

— systemovich

@Geoffrey van Wyk - वास्तव में? मैंने कभी किसी को इन टेम्पलेट फ़ाइलों के बाहर का उपयोग करते नहीं देखा। वे बेहद अस्थिर हैं, लेकिन प्रत्येक अपने स्वयं के लिए, मुझे लगता है।

— क्रेग

@Craige: PHP द्वारा समर्थित किसी भी भाषा का निर्माण "बेहद अस्थिर" नहीं है - PHP दुभाषिया परिभाषित करता है कि "मानक" क्या है।

— बिली ओनेल

Ada के पास अधिकांश निर्माणों के अंत के लिए विशिष्ट मार्कर हैं if ... then ... end if; while ... loop ... end loop; procedure Foo is ... end Foo;:। मुझे लगता है कि यह सुगमता में मदद करता है (और यह संकलक द्वारा जांचा जाता है, जो टिप्पणियां नहीं हैं)।

— कीथ थॉम्पसन

Answer 1

मैं कहूंगा कि यदि आप कोड इतना लंबा है कि आप आसानी से अपने ब्रेसिज़ का पालन नहीं कर सकते हैं, तो अधिकांश भाषाओं के लिए आपके कोड को रिफैक्टिंग की आवश्यकता है।

हालाँकि, टेम्प्लेटिंग भाषाओं (जैसे PHP) में यह मान्य हो सकता है, क्योंकि आपके पास HTML का एक बड़ा ब्लॉक हो सकता है जो स्थिति या लूप संरचना की शुरुआत और अंत को अलग करता है।

Comments

PHP के लिए पूरी तरह से मान्य बिंदु, यदि आप Html के साथ मिश्रित PHP का उपयोग कर रहे हैं। Gryffindor के लिए 1 अंक।

यहां तक ​​कि पीएचपी के साथ HTML के साथ मिश्रित एक अस्थायी भाषा के रूप में आप अभी भी इंडेंट कर सकते हैं। PHP का उपयोग एक अस्थायी भाषा के रूप में करते समय भी आपको ब्रेसिज़ का उपयोग नहीं करना चाहिए, बल्कि निर्माण while(): endwhile;और foreach(): endforeach;निर्माण आदि करना चाहिए

— Htbaa

मैं वास्तव में नहीं देख रहा हूँ कि आपको PHP को क्यों नहीं अपनाना चाहिए। शायद दूसरी भाषा में।

— टॉम हॉकिन -

@ हतबा: मैं विश्वास नहीं कर सकता कि मैं इस समय PHP का उपयोग कर रहा हूं और उन लोगों के बारे में नहीं जानता। धन्यवाद! इंडेंटिंग के बारे में, मैं सशर्त HTML को बाकी पेज की तरह ही इंडेंट रखना पसंद करता हूं, बजाय इसके कि इसे बनाने वाले PHP के अनुरूप।

— मैट एलेन

@ टॉम: मैं हँसा, लेकिन दोषी महसूस करता हूँ। : पी

Answer 2

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

Answer 3

यह एक भयानक अभ्यास है जो कई कारकों द्वारा अप्रचलित है।

• अधिकांश आधुनिक IDE इसी ब्रेस को हाइलाइट करते हैं जब कैरेट दोनों के प्रतीक पर होता है।
• यदि आप सफाई से कोडिंग कर रहे हैं, तो आपको शायद ही कोई जगह मिलेगी जहाँ आपका तरीका 10 लाइनों से अधिक हो।

मैं इस मानसिकता वाले बहुत सारे जावा प्रोग्रामर को नोटिस करता हूं, और यह जावा कोड को वास्तव में गंदा दिखता है और फोकस को कोड से हटाकर टिप्पणियों की ओर ले जाता है।

इसका उपयोग करने के खिलाफ अत्यधिक सुझाव दें।

Comments

मेरे पास एक सहकर्मी (जावा डेवलपर) है जो ऐसा करता है। इसके बजाय // के लिए और // अगर वह // रफ और // का उपयोग करता है। यह मुझे पागल कर देता है और वह इसे हर जगह करता है।

— जय

हाँ, मैं एक है कि इस पर जोर दिया था। AAAAAGHHHHH।

— रिग

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

— जेस्पर 10

+1 के लिए "एक भयानक अभ्यास है"।

— स्क्यूलिफ

Answer 4

कोड को लिखे जाने की तुलना में 10 गुना अधिक पढ़ा जाता है।

यदि यह पढ़ने में आसान बनाता है, तो इसे करें।

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

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

Comments

यह है बुरा। यहां तक ​​कि शुरुआती स्तर की पाठ्यपुस्तकें भी यह अत्याचार नहीं करती हैं। "कोड को लिखे जाने की तुलना में 10 गुना अधिक पढ़ा जाता है" ... इस कोड के साथ पाठक के समय को बर्बाद नहीं करने के लिए सभी और अधिक कारण।

— थॉमस ईडिंग

@trinithis यदि आपके पास 20-केस स्विच स्टेटमेंट है तो क्या होगा? कभी-कभी आपको 20 विभिन्न विकल्पों का समर्थन करने की आवश्यकता होती है, और यह बेहतर है कि उन्हें एक जगह पर "रिफैक्टर्ड" की तुलना में कुछ बहु-स्तरीय निर्णय लेने वाली योजना में इकट्ठा किया जाए।

— quant_dev 10

मेरा मानना ​​है कि यह कोडर्स द्वारा एक अभ्यास है जो साथियों को कम आंकते हैं :) कि अन्य लोग कोड को पढ़ने के लिए पर्याप्त रूप से चालाक नहीं होते हैं। आमतौर पर मैं इस प्रथा के खिलाफ हूं, लेकिन ठीक है अगर कोई ऐसा करता है तो वहां जंगल है जो शायद ही पढ़ने योग्य हो। मुझे लगता है कि वैसे भी मत करो!

— WinW

@trinithis इसके बारे में नहीं है कि यह बुरा है या नहीं, यह लोगों को बेहतर तरीके से मदद करने के प्रभावी तरीकों के बारे में है ताकि वे इसके माध्यम से विकसित हों। प्रभावी होना> सही होना। यह भी एक पूरी तरह से समझदार बात है अगर, कहते हैं, आप विरासत कोड refactoring कर रहे हैं जो कि एक गड़बड़ है। कभी-कभी बुरी चीजें बेहतर अंतरिम कदम बना सकती हैं और इससे कुछ बेहतर भी हो सकता है।

— लूनीवोर

@trinithis क्षमा करें, जब आप एक लाइन पर सभी को पसंद करते हैं तो मैं इसका मतलब नहीं निकाल सकता। मुझे लगता है कि मैंने उल्लेख किया है कि कोड को रिफैक्ट करने के अन्य तरीके भी हैं जो ऐसा करने वाले देवता सीख सकते हैं।

— लुनिवर

Answer 5

मुझे इस तरह की चीज़ों से भरा एक बड़ा (C ++) कोड आधार मिल गया है:

int Class::AccessorMethod(void)
{
    return privateValue;
}//end AccessorMethod

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

Comments

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

— PSU

C ++ में यद्यपि मैं अक्सर छिपी कार्यान्वयन सामग्री के लिए शीर्ष पर अनाम नामस्थान खोलूंगा। फिर कुछ बिंदु पर मैं इस ब्रेस को बंद कर देता हूं और यह जानना उपयोगी होता है कि क्लोज-ब्रेस का मतलब यहां क्या है।

— कैशकॉ

Answer 6

C ++ में दो होल्डओवर हैं जहां यह अभी भी उपयोगी है और "अपने कोड को विभाजित करने" की सलाह के लिए आवश्यक पकड़ नहीं है:

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

2. #Ifdef / #endif जोड़ियों के लिए। कभी-कभी सशर्त संकलन के लिए बहुत सारे कोड होते हैं, यह घोंसले के शिकार के साथ बुरा हो सकता है, और संपादक हम अक्सर भारी-भारी "सहायक" का उपयोग करते हैं, इंडेंटेशन को समाप्त कर देते हैं, इसलिए टिप्पणियां त्वरित अवलोकन के दौरान उपयोगी होती हैं।

Comments

नाम स्थान की टिप्पणी और कारणों के लिए +1। केवल यही समय है जब मैं ऐसा करता हूं और इसी कारण से

— जॉन

+ लंबे स्विच बयान।

— quant_dev

Answer 7

मेरे लिए कोड को उस तरह की टिप्पणी जोड़ने के लिए भ्रमित होना होगा जो आपने निर्दिष्ट किया था।

अगर यह सिर्फ कहते हैं // IF स्टेटमेंट तब आपको आश्चर्य हुआ कि यह पहली जगह में क्यों है।

Comments

मैं सहमत हूं, यह एक लाइन की तरह दिखता है, जिस पर एक पुराने स्कूल के बजाय टिप्पणी की गई है//endif

— स्टुपेरयूसर

Answer 8

यह देखने का विकल्प कि आपका ब्रेस बंद हो रहा है, एक ही कॉलम पर क्लोजिंग एक के समान है। मुझे लगता है कि बहुत स्पष्ट और अधिक पठनीय है।

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

Answer 9

यह मोटे तौर पर 80x24 कैरेक्टर टर्मिनल विंडो में काम करने के पुराने दिनों से एक होल्डओवर है, खासकर यदि आप ईवीई जैसे विंडो एडिटर का उपयोग कर रहे थे। अब भी, मैं अपना अधिकतर काम टर्मिनल सत्र में vim का उपयोग करते हुए करता हूं, और मैं सत्र को तीन या चार सबवॉइस में विभाजित कर सकता हूं, इसलिए मैं केवल किसी एक समय में कुछ लाइनें देख सकता हूं।

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

Answer 10

आप मूल रूप से सभी वैध कारण देते हैं कि इसका उपयोग क्यों न करें हर सभ्य प्रोग्रामर को ये लागू करना चाहिए। तो लोग इसका उपयोग क्यों करते हैं ? क्योंकि वे इसे गलत कर रहे हैं और बेहतर नहीं जानते हैं।

Comments

erm, कृपया नीचे बताएं। मैंने केवल इस उत्तर का आविष्कार नहीं किया, यह एक वास्तविक जीवन के अनुभव से उपजा है: मेरे कोलीगेट जो मेरे बगल में एक-दो फीट बैठे हैं, वह 10 से अधिक कानों के लिए प्रोग्रामिंग कर रहे हैं और उनके बारे में कोई सुराग नहीं था कि यह गलत क्यों है जब तक मैंने उन्हें समझाया नहीं ।

— stijn

संभवतः इसका उपयोग कुछ पाठ्यपुस्तक में किया गया था ताकि लोगों का एक समूह इसका उपयोग करके कॉलेज से बाहर आए? यह एक परिचयात्मक पाठ में एक स्थान हो सकता है। प्रीप्रोसेसर में यथोचित रूप से मान्य, विशेष रूप से # ifdef / एंडिफ़ में गार्ड शामिल हैं

— मार्टिन बेकेट