एक बात का अभी तक किसी ने उल्लेख नहीं किया है, इसलिए मैं इसका उल्लेख करूंगा: टिप्पणी करने की इच्छा अक्सर इंगित करती है कि प्रोग्रामर डूइंग इट गलत है।
पहले, मान लें कि प्रोग्रामर को केवल "नेस्टिंग" या "नेस्टिंग नहीं" दिखाई देता है, जब प्रोग्रामर कुछ इस तरह से संरचनात्मक रूप से लिखता है:
do_something();
/* comment /* nested comment */ more comment */
do_something_else();
अब, ऐसी बात व्यवहार में कब आती है? निश्चित रूप से प्रोग्रामर नेस्टेड टिप्पणी लिखने वाला नहीं है जो कि वास्तव में उपरोक्त स्निपेट जैसा दिखता है! नहीं, व्यवहार में जब हम टिप्पणी करते हैं (या चाहें तो हम उन्हें घोंसला बना सकते हैं), ऐसा इसलिए है क्योंकि हम कुछ इस तरह लिखना चाहते हैं:
do_something(); /* do a thing */
/* [ajo] 2017-12-03 this turned out to be unnecessary
do_something_else(); /* do another thing */
*/
और यह BAD है। यह एक पैटर्न नहीं है जिसे हम (भाषा डिजाइनर के रूप में) प्रोत्साहित करना चाहते हैं! उपरोक्त स्निपेट लिखने का सही तरीका है:
do_something(); /* do a thing */
वह "गलत" कोड, वह झूठी शुरुआत या जो कुछ भी था, कोडबेस में नहीं है। यह स्रोत नियंत्रण इतिहास में, सबसे अच्छे रूप में है। आदर्श रूप में, आपने कभी भी सही के साथ शुरू करने के लिए गलत कोड नहीं लिखा होगा? और अगर गलत कोड वहाँ एक उद्देश्य की सेवा कर रहा था, तो चेतावनी बनाए रखने वाले किसी कारण के लिए इसे बहाल नहीं करने के लिए, ठीक है, कि शायद एक अच्छी तरह से लिखा और जानबूझकर कोड टिप्पणी के लिए एक नौकरी है । केवल कुछ पुराने कोड को छोड़कर "एक्स नहीं करते" को व्यक्त करने की कोशिश कर रहा है, लेकिन एक्स ने टिप्पणी की, लोगों को एक्स करने से रोकने के लिए सबसे पठनीय या प्रभावी तरीका नहीं है।
यह सब अंगूठे के एक सरल नियम से उबलता है जिसे आपने पहले सुना होगा: कोड बाहर टिप्पणी न करें। (इस वाक्यांश के लिए खोज करने से समझौते में बहुत सारी राय बदल जाएगी ।)
इससे पहले कि आप पूछें: हाँ, C, C #, और C ++ जैसी भाषाएं प्रोग्रामर को कोड के बड़े ब्लॉक को "कमेंट आउट" करने के लिए पहले से ही एक और टूल देती हैं #if 0:। लेकिन यह सी प्रीप्रोसेसर का सिर्फ एक विशेष अनुप्रयोग है, जो अपने आप में एक बड़ा और उपयोगी उपकरण है। यह वास्तव में अत्यंत कठिन और विशेष भाषा के लिए सशर्त संकलन का समर्थन करने के लिए #ifऔर अभी तक समर्थन नहीं करेगा #if 0।
इसलिए, हमने स्थापित किया है कि नेस्टेड टिप्पणियां तभी प्रासंगिक हैं जब प्रोग्रामर कोड टिप्पणी कर रहा हो; और हमने स्थापित किया है (बहुत सारे अनुभवी प्रोग्रामर्स की आम सहमति के माध्यम से) जो कोड को कमेंट करते हैं वह एक बैड थिंग है।
सिओलोगिज्म को पूरा करने के लिए, हमें यह स्वीकार करना चाहिए कि भाषा डिजाइनरों को अच्छी चीजों को बढ़ावा देने और बुरी चीजों को हतोत्साहित करने में रुचि है (यह मानते हुए कि बाकी सभी समान हैं)।
नेस्टेड टिप्पणी के मामले में, और सब है बराबर - आप सुरक्षित रूप से अनदेखा कर सकते हैं कम मतदान जवाब है कि दावा है कि नेस्ट पार्सिंग /*किसी भी तरह पार्सर के लिए "मुश्किल" होगा। (नेस्टेड नस्टेड की /*तुलना में कठिन नहीं हैं (, जो कि दुनिया के हर पार्सर के बारे में पहले से ही संभालने की जरूरत है।)
तो, बाकी सभी समान होने चाहिए, क्या एक भाषा डिजाइनर को टिप्पणी करने में आसान बनाना चाहिए (यानी, कोड टिप्पणी करने के लिए), या मुश्किल? याद रखें कि कोड टिप्पणी करना एक बुरी बात है।
QED
पाद लेख। ध्यान दें कि यदि आप नेस्टेड टिप्पणियों की अनुमति नहीं देते हैं, तो
hello /* foo*/bar.txt */ world
एक भ्रामक "टिप्पणी" है - यह इसके बराबर है
hello bar.txt */ world
(जो एक वाक्यविन्यास त्रुटि की संभावना है)। लेकिन अगर आप कर नेस्टेड टिप्पणियों की अनुमति है, तो
hello /* foo/*.txt */ world
एक भ्रामक "टिप्पणी" है - यह इसके बराबर है
hello
लेकिन टिप्पणी फ़ाइल के अंत में सभी तरह से खुला छोड़ देता है (जो फिर से लगभग निश्चित रूप से एक वाक्यविन्यास त्रुटि है)। इसलिए न तो रास्ता विशेष रूप से अनजाने वाक्यविन्यास त्रुटियों के लिए कम संभावना है। एकमात्र अंतर यह है कि वे टिप्पणी-आउट कोड के जानबूझकर एंटीपैटर्न को कैसे संभालते हैं ।