जटिल कोड की व्याख्या करने वाली टिप्पणियों में क्या गलत है?


236

बहुत सारे लोग दावा करते हैं कि "टिप्पणियों में 'क्यों' की व्याख्या होनी चाहिए, लेकिन 'कैसे' नहीं।" दूसरों का कहना है कि "कोड को स्व-दस्तावेजीकरण होना चाहिए" और टिप्पणियों को दुर्लभ होना चाहिए। रॉबर्ट सी। मार्टिन का दावा है कि (मेरे अपने शब्दों में कहा गया है) अक्सर "टिप्पणियां बुरी तरह से लिखे गए कोड के लिए माफी हैं"।

मेरा प्रश्न निम्नलिखित है:

एक जटिल एल्गोरिथ्म या एक वर्णनात्मक टिप्पणी के साथ कोड का एक लंबा और जटिल टुकड़ा समझाने के साथ क्या गलत है?

इस तरह, अन्य डेवलपर्स के बजाय (स्वयं सहित) यह पता लगाने के लिए लाइन द्वारा पूरी एल्गोरिथ्म लाइन को पढ़ने के लिए कि वह क्या करता है, वे बस मैत्रीपूर्ण अंग्रेजी में आपके द्वारा लिखी गई मित्रवत वर्णनात्मक टिप्पणी पढ़ सकते हैं।

मानव द्वारा आसानी से समझे जाने के लिए अंग्रेजी 'डिज़ाइन' है। हालांकि, जावा, रूबी या पर्ल को मानव-पठनीयता और कंप्यूटर-पठनीयता को संतुलित करने के लिए डिज़ाइन किया गया है, इस प्रकार यह पाठ की मानव-पठनीयता से समझौता करता है। एक मानव अंग्रेजी के एक टुकड़े को बहुत तेजी से समझ सकता है कि वह एक ही अर्थ के साथ कोड का एक टुकड़ा समझ सकता है (जब तक कि ऑपरेशन तुच्छ नहीं है)।

तो एक आंशिक रूप से मानव-पठनीय प्रोग्रामिंग भाषा में लिखे गए कोड का एक जटिल टुकड़ा लिखने के बाद, अनुकूल और समझ में आने वाली अंग्रेजी में कोड के संचालन की व्याख्या करते हुए एक वर्णनात्मक और संक्षिप्त टिप्पणी क्यों नहीं जोड़नी चाहिए?

कुछ कहेंगे "कोड को समझना मुश्किल नहीं होना चाहिए", "फ़ंक्शन को छोटा बनाएं", "वर्णनात्मक नाम का उपयोग करें", "स्पेगेटी कोड न लिखें"।

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

क्या यह वास्तव में सामान्य ऑपरेशन के बारे में टिप्पणियों की कुछ पंक्तियों के साथ एक जटिल एल्गोरिथ्म की व्याख्या करना बुरा है? एक टिप्पणी के साथ जटिल कोड की व्याख्या करने में क्या गलत है?


14
यदि ऐसा है कि जटिल है, तो इसे छोटे टुकड़ों में फिर से बनाने का प्रयास करें।
वॉन हिल्ट्स

151
सिद्धांत रूप में, सिद्धांत और व्यवहार में कोई अंतर नहीं है। व्यवहार में, है।
स्कॉट लेडले

5
@mnnnz: अधिक सीधे, उस समय जब आप टिप्पणी लिखते हैं तो आप इस समस्या को हल कर लेते हैं। अगली बार जब आप यात्रा करेंगे, तो आपके पास इस समस्या से कम क्षमता होगी ।
स्टीव जेसोप

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

11
मुझे लगता है कि नीचे दी गई कई प्रतिक्रियाएं आपके प्रश्न का उद्देश्यपूर्ण रूप से गलत वर्णन कर रही हैं। आपके कोड पर टिप्पणी करने में कुछ भी गलत नहीं है। यदि आपको लगता है कि आपको एक व्याख्यात्मक टिप्पणी लिखने की आवश्यकता है, तो आपको इसकी आवश्यकता है।
टोनी एननिस

जवाबों:


408

आम आदमी की शर्तों में:

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

जमीनी स्तर:

खुद को समझाना अच्छा है, ऐसा करने की जरूरत नहीं बेहतर है।


91
नियोक्ता के धन पुनर्लेखन कोड को अधिक आत्म-व्याख्यात्मक बनाने के लिए खर्च करना उचित ठहराना अक्सर असंभव होता है, जब एक अच्छी टिप्पणी बहुत कम समय में काम कर सकती है। एक कर्तव्यनिष्ठ प्रोग्रामर को हर बार अपने फैसले का उपयोग करना चाहिए।
किस्सा

34
@aecolley के साथ शुरू करने के लिए स्व-व्याख्यात्मक कोड लिखना अभी तक बेहतर है।
ट्यूलेंस कोर्डोवा

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

62
@rwong: इसके विपरीत, मैं अक्सर अपने आप को व्यावसायिक तर्क में अधिक टिप्पणियां लिखता हुआ पाता हूं, क्योंकि यह बताना महत्वपूर्ण है कि कोड को बताई गई आवश्यकताओं के साथ कैसे बनाया जाता है: "यह वह रेखा है जो धारा धोखाधड़ी के तहत हम सभी को जेल जाने से रोकती है। दंड संहिता "। यदि यह सिर्फ एक एल्गोरिथ्म है, ठीक है, एक प्रोग्रामर उद्देश्य को खरोंच से पूरी तरह से पता लगा सकता है यदि आवश्यक हो। व्यावसायिक तर्क के लिए आपको एक ही समय में एक ही कमरे में एक वकील और क्लाइंट की आवश्यकता होती है। संभवत: मेरी "सामान्य ज्ञान" औसत एप्लिकेशन प्रोग्रामर के ;-) से एक अलग डोमेन में है
स्टीव जेसप

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

110

कोड के जटिल या भ्रमित होने के विभिन्न कारणों का एक गुच्छा है। सबसे आम कारणों सबसे अच्छा यह कम भ्रामक किसी भी तरह की टिप्पणियां जोड़कर नहीं बनाने के लिए कोड पुनर्रचना से संबोधित कर रहे हैं।

हालांकि, ऐसे मामले हैं जहां एक अच्छी तरह से चुनी गई टिप्पणी सबसे अच्छा विकल्प है।

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

  • यदि आपने कुछ ऐसा लिया है जिसे किसी विशेष संकेतन में एक या दो पंक्तियों के रूप में लिखा जा सकता है और इसे अनिवार्य कोड के बड़े ग्लोब में विस्तारित किया जा सकता है, तो फ़ंक्शन के ऊपर एक टिप्पणी में उन विशेष संकेतन की एक या दो पंक्तियों को डालना एक अच्छा तरीका है। पाठक को बताएं कि वह क्या करने वाला है। यह "लेकिन अगर कोड के साथ टिप्पणी सिंक से बाहर हो जाती है" तो यह एक अपवाद है, क्योंकि विशेष संकेतन कोड की तुलना में बग खोजने में बहुत आसान है। (यदि आप इसके बजाय अंग्रेजी में विनिर्देश लिखे हैं तो यह दूसरा तरीका है।) एक अच्छा उदाहरण यहाँ है: https://dxr.mozilla.org/mozilla-central/source/layout/style/nsCSSScanner.cpp##57 ...

    /**
     * Scan a unicode-range token.  These match the regular expression
     *
     *     u\+[0-9a-f?]{1,6}(-[0-9a-f]{1,6})?
     *
     * However, some such tokens are "invalid".  There are three valid forms:
     *
     *     u+[0-9a-f]{x}              1 <= x <= 6
     *     u+[0-9a-f]{x}\?{y}         1 <= x+y <= 6
     *     u+[0-9a-f]{x}-[0-9a-f]{y}  1 <= x <= 6, 1 <= y <= 6
    
  • कोड समग्र सीधा है, लेकिन एक या दो चीजें हैं जो हैं, तो देखने के लिए जरूरत से ज्यादा जटिल, अनावश्यक, या पूरी तरह से गलत है, लेकिन क्योंकि कई कारणों से इस तरह से होना जरूरी है, तो आप एक टिप्पणी को ठीक उसके ऊपर संदेहास्पद दिखने सा है, जो में डाल आप कारण बताते हैं । यहां एक सरल उदाहरण है, जहां केवल एक चीज की व्याख्या करने की आवश्यकता है वह यह है कि एक स्थिर का एक निश्चित मूल्य क्यों है।

    /* s1*s2 <= SIZE_MAX if s1 < K and s2 < K, where K = sqrt(SIZE_MAX+1) */
    const size_t MUL_NO_OVERFLOW = ((size_t)1) << (sizeof(size_t) * 4);
    if ((nmemb >= MUL_NO_OVERFLOW || size >= MUL_NO_OVERFLOW) &&
        nmemb > 0 && SIZE_MAX / nmemb < size)
      abort();
    

25
यही कारण है कि एक उल्लंघन है, 4होना चाहिए CHAR_BIT / 2;-)
स्टीव जेसप

@SteveJessop: क्या कुछ लागू होगा जहां CHAR_BITS16 था और sizeof (size_t) 2 था, लेकिन size_t का अधिकतम मूल्य 2 ^ 20 [12 आकार वाले पैडिंग बिट्स] था?
सुपरकट

2
@supercat मैं कुछ भी स्पष्ट रूप से precludes कि C99, में जो इसका मतलब है कि उदाहरण नहीं दिख रहा है तकनीकी रूप से गलत है। यह OpenBSD के (थोड़ा संशोधित संस्करण) से लिया जाता है reallocarray, और OpenBSD आमतौर पर उन संभावनाओं को पूरा करने में विश्वास नहीं करता है जो उनके ABI में नहीं होती हैं ।
zwol

3
@Zack: यदि कोड POSIX मान्यताओं के आसपास बनाया गया है, तो CHAR_BITS का उपयोग करके यह धारणा दी जा सकती है कि कोड 8. के ​​अलावा अन्य मानों के साथ काम कर सकता है
supercat

2
@Zack: उपयोगी होने के लिए सटीक-चौड़ाई वाले अहस्ताक्षरित प्रकारों के लिए, उनके शब्दार्थ को आकार के स्वतंत्र रूप से परिभाषित करने की आवश्यकता होगी int। जैसा कि दिया गया है uint32_t x,y,z;, का अर्थ (x-y) > zआकार के आधार पर निर्भर करता है int। इसके अलावा, मजबूत कोड लिखने के लिए डिज़ाइन की गई भाषा को प्रोग्रामर्स को एक प्रकार के बीच अंतर करने की अनुमति देनी चाहिए, जहां कम्प्यूटेशंस की सीमा से अधिक होने की उम्मीद है और चुपचाप लपेटना चाहिए, बनाम एक प्रकार जहां कम्प्यूटेशंस की रेंज को पार करना चाहिए, बनाम जहां कम्प्यूटेशंस। प्रकार की सीमा से अधिक होने की उम्मीद नहीं है, लेकिन ...
सुपरकैट

61

तो एक टिप्पणी के साथ जटिल कोड की व्याख्या करने में क्या गलत है?

यह सही या गलत का सवाल नहीं है, लेकिन 'सर्वोत्तम अभ्यास' का है, जैसा कि विकिपीडिया लेख में बताया गया है :

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

इसलिए सबसे अच्छा अभ्यास यह है कि पहले कोड को बेहतर बनाने की कोशिश की जाए, और यदि संभव न हो तो अंग्रेजी का उपयोग करें।

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


42
+1 के लिए "यह टिप्पणी की कोड कि रिफैक्टर्ड कोड से पुनर्रचना के लिए जरूरी है कि टिप्पणियों की आवश्यकता को खोजने के लिए और अधिक आम है"
ब्रैंडन

7
ठीक है, लेकिन वह टिप्पणी कितनी बार है://This code seriously needs a refactor
एरिक रेपेने

2
बेशक, एक कठोर वैज्ञानिक अध्ययन द्वारा समर्थित नहीं तथाकथित कोई भी सर्वोत्तम अभ्यास केवल एक राय है।
ब्लर एफएल

54

एक दिन आएगा जब आपका सुंदर, पूरी तरह से तैयार किया गया, अच्छी तरह से संरचित और पठनीय कोड काम नहीं करेगा। या यह बहुत अच्छी तरह से काम नहीं करेगा। या एक विशेष मामला उत्पन्न होगा जहां यह काम नहीं करता है और समायोजन की आवश्यकता है।

उस बिंदु पर, आपको कुछ ऐसा करने की आवश्यकता होगी जो चीजों को बदल दे ताकि यह सही ढंग से काम करे। विशेष रूप से उस मामले में जहां प्रदर्शन की समस्याएं हैं, लेकिन अक्सर उन परिदृश्यों में भी जहां पुस्तकालयों, एपीआई, वेब सेवाओं, रत्नों या ऑपरेटिंग सिस्टम में से एक जो आप के साथ काम कर रहे हैं, उम्मीद के मुताबिक व्यवहार नहीं करते हैं, आप उन सुझावों को समाप्त कर सकते हैं जो नहीं हैं जरूरी अयोग्य, लेकिन प्रति-सहज या गैर-स्पष्ट हैं।

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

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

इसलिए मैं बुरे कोड के लिए माफी के रूप में टिप्पणियों के बारे में नहीं सोचता, लेकिन शायद इस बात के स्पष्टीकरण के रूप में कि आपने स्पष्ट काम क्यों नहीं किया। बीत रहा है // The standard approach doesn't work against the 64 bit version of the Frobosticate Libraryकोड और कहा कि पुस्तकालय के खिलाफ परीक्षण के उस भाग पर ध्यान देना अपने भविष्य स्वयं सहित भविष्य डेवलपर्स,, की अनुमति देगा। यकीन है, आप अपने स्रोत नियंत्रण टिप्पणियों में भी टिप्पणी डाल सकते हैं, लेकिन लोग केवल उन पर ध्यान देंगे जो कुछ गलत हो गया है। कोड बदलते ही वे कोड कमेंट पढ़ेंगे।

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

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


5
@ क्रिसियन क्या है? पहली पंक्ति उस कथन को संदर्भित करती है, निश्चित रूप से, लेकिन उससे परे यह थोड़ा व्यापक है क्योंकि मैं इसे समझता हूं।
ग्लेनट्रॉन

9
"जब भी मैं अपने पुराने कोड को पढ़ता हूं, तो मैं अपने अतीत की कसम खाता हूं। मेरे विकास के कैरियर में चार साल और मुझे लगता है कि यह एक घटना है जब भी मैं 6 महीने या उससे अधिक उम्र के किसी भी चीज को देखता हूं।
केन

6
कई मामलों में, सबसे अधिक जानकारीपूर्ण और उपयोगी ऐतिहासिक जानकारी उन चीजों से संबंधित है जिनके बारे में विचार किया जाता है, लेकिन उनके खिलाफ निर्णय लिया जाता है। ऐसे कई मामले हैं, जहां कोई व्यक्ति किसी चीज के लिए एक्स को चुनता है और कुछ अन्य को वाई बेहतर लगता है; उन मामलों में से कुछ में, वाई एक्स की तुलना में "लगभग" बेहतर काम करेगा, लेकिन कुछ दुर्गम समस्याएं हैं। तो Y क्योंकि उन समस्याओं में से परहेज किया गया था, इस तरह के ज्ञान में मदद कर सकते दृष्टिकोण वाई लागू करने के लिए असफल प्रयासों पर अपने समय बर्बाद करने से दूसरों को रोकने
supercat

4
दिन-प्रतिदिन के आधार पर मैं प्रगति टिप्पणियों में काम का उपयोग बहुत अधिक करता हूं- वे लंबे समय तक नहीं रहते हैं, लेकिन TODO नोट या एक छोटे खंड में छोड़ना मुझे यह याद दिलाने के लिए कि मैं आगे क्या करने जा रहा हूं, एक उपयोगी हो सकता है। सुबह याद दिलाएं।
ग्लेनट्रॉन

1
@ लिलिअन्थल, मुझे नहीं लगता कि अंतिम पैरा व्यक्तिगत परियोजनाओं तक ही सीमित है- उन्होंने कहा "... मैं अभी भी उन हिस्सों पर टिप्पणी करता हूं जो मुझे भ्रमित करने वाले लगते हैं ।"
वाइल्डकार्ड

29

टिप्पणियों की आवश्यकता कोड के अमूर्त स्तर के व्युत्क्रमानुपाती होती है।

उदाहरण के लिए, असेंबली लैंग्वेज सबसे व्यावहारिक उद्देश्यों के लिए है, टिप्पणियों के बिना अनजाने। यहाँ एक छोटे से कार्यक्रम का अंश दिया गया है जो फाइबोनैचि श्रृंखला की शर्तों की गणना करता है और छापता है :

main:   
; initializes the two numbers and the counter.  Note that this assumes
; that the counter and num1 and num2 areas are contiguous!
;
    mov ax,'00'                     ; initialize to all ASCII zeroes
    mov di,counter                  ; including the counter
    mov cx,digits+cntDigits/2       ; two bytes at a time
    cld                             ; initialize from low to high memory
    rep stosw                       ; write the data
    inc ax                          ; make sure ASCII zero is in al
    mov [num1 + digits - 1],al      ; last digit is one
    mov [num2 + digits - 1],al      ; 
    mov [counter + cntDigits - 1],al

    jmp .bottom         ; done with initialization, so begin

.top
    ; add num1 to num2
    mov di,num1+digits-1
    mov si,num2+digits-1
    mov cx,digits       ; 
    call    AddNumbers  ; num2 += num1
    mov bp,num2         ;
    call    PrintLine   ;
    dec dword [term]    ; decrement loop counter
    jz  .done           ;

    ; add num2 to num1
    mov di,num2+digits-1
    mov si,num1+digits-1
    mov cx,digits       ;
    call    AddNumbers  ; num1 += num2
.bottom
    mov bp,num1         ;
    call    PrintLine   ;
    dec dword [term]    ; decrement loop counter
    jnz .top            ;
.done
    call    CRLF        ; finish off with CRLF
    mov ax,4c00h        ; terminate
    int 21h             ;

टिप्पणियों के साथ भी, यह काफी जटिल हो सकता है।

आधुनिक उदाहरण: रेग्जेस अक्सर बहुत कम अमूर्त निर्माण होते हैं (निचले मामले पत्र, संख्या 0, 1, 2, नई लाइनें, आदि)। उन्हें शायद नमूनों के रूप में टिप्पणियों की आवश्यकता है (बॉब मार्टिन, IIRC, यह स्वीकार करता है)। यहाँ एक regex है जो मुझे लगता है कि HTTP (S) और FTP URL से मेल खाना चाहिए:

^(((ht|f)tp(s?))\://)?(www.|[a-zA-Z].)[a-zA-Z0-9\-\.]+\.(com|edu|gov|m
+il|net|org|biz|info|name|museum|us|ca|uk)(\:[0-9]+)*(/($|[a-zA-Z0-9\.
+\,\;\?\'\\\+&amp;%\$#\=~_\-]+))*$

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

मैं सोच रहा हूँ सी में न्यूमेरिकल व्यंजनों ज्यादातर को शब्दशः अनुवाद सी ++ में न्यूमेरिकल व्यंजनों , जो मैं अनुमान कर के रूप में शुरू न्यूमेरिकल व्यंजनों (FORTAN में), सभी चर के साथ a, aa, b, c, cc, आदि प्रत्येक संस्करण के माध्यम से बनाए रखा। एल्गोरिदम सही हो सकता है, लेकिन उन्होंने प्रदान की गई भाषाओं के सार का लाभ नहीं उठाया। और उन्होंने पी *** मुझे बंद कर दिया। डॉ। डॉब्स लेख से नमूना - फास्ट फूरियर ट्रांसफॉर्म :

void four1(double* data, unsigned long nn)
{
    unsigned long n, mmax, m, j, istep, i;
    double wtemp, wr, wpr, wpi, wi, theta;
    double tempr, tempi;

    // reverse-binary reindexing
    n = nn<<1;
    j=1;
    for (i=1; i<n; i+=2) {
        if (j>i) {
            swap(data[j-1], data[i-1]);
            swap(data[j], data[i]);
        }
        m = nn;
        while (m>=2 && j>m) {
            j -= m;
            m >>= 1;
        }
        j += m;
    };

    // here begins the Danielson-Lanczos section
    mmax=2;
    while (n>mmax) {
        istep = mmax<<1;
        theta = -(2*M_PI/mmax);
        wtemp = sin(0.5*theta);
        wpr = -2.0*wtemp*wtemp;
        wpi = sin(theta);
        wr = 1.0;
        wi = 0.0;
        for (m=1; m < mmax; m += 2) {
            for (i=m; i <= n; i += istep) {
                j=i+mmax;
                tempr = wr*data[j-1] - wi*data[j];
                tempi = wr * data[j] + wi*data[j-1];

                data[j-1] = data[i-1] - tempr;
                data[j] = data[i] - tempi;
                data[i-1] += tempr;
                data[i] += tempi;
            }
            wtemp=wr;
            wr += wr*wpr - wi*wpi;
            wi += wi*wpr + wtemp*wpi;
        }
        mmax=istep;
    }
}

अमूर्तता के बारे में एक विशेष मामले के रूप में, हर भाषा में कुछ सामान्य कार्यों के लिए मुहावरे / विहित कोड स्निपेट होते हैं (C में डायनामिक लिंक्ड लिस्ट डिलीट करना), और इस बात की परवाह किए बिना कि वे कैसे प्रलेखित नहीं होने चाहिए। प्रोग्रामर को इन मुहावरों को सीखना चाहिए, क्योंकि वे अनौपचारिक रूप से भाषा का हिस्सा हैं।

तो दूर ले जाओ: गैर-मुहावरेदार कोड निम्न-स्तर के बिल्डिंग ब्लॉक्स से बनाया गया है जिसे टाला नहीं जा सकता टिप्पणी की जरूरत है। और यह आवश्यक है कि यह कम से कम WAAAAY होता है।


1
किसी को वास्तव में विधानसभा भाषा में इस तरह की एक पंक्ति नहीं लिखनी चाहिए dec dword [term] ; decrement loop counter:। दूसरी ओर, आपकी असेंबली लैंग्वेज मिसिंग क्या है, प्रत्येक "कोड पैराग्राफ" के पहले एक टिप्पणी है जो यह समझाती है कि कोड का अगला ब्लॉक क्या करता है। उस स्थिति में, टिप्पणी आमतौर पर छद्मकोड में एक पंक्ति के समान होगी, जैसे कि ;clear the screen, 7 पंक्तियों के बाद यह वास्तव में स्क्रीन को साफ करने के लिए लेता है।
स्कॉट व्हिटलॉक

1
हां, विधानसभा के नमूने में मैं कुछ अनावश्यक टिप्पणियों पर विचार करूंगा, लेकिन निष्पक्ष होने के लिए, यह 'गुड' असेंबली शैली का सुंदर प्रतिनिधि है। यहां तक ​​कि एक या दो लाइन पैराग्राफ प्रस्तावना के साथ, कोड का पालन करना वास्तव में कठिन होगा। मैं FFT उदाहरण से बेहतर ASM नमूने को समझता था। मैंने C ++ में ग्रेड स्कूल में एक FFT प्रोग्राम किया, और यह इस तरह से कुछ भी नहीं दिखता था, लेकिन तब हम एसटीएल, पुनरावृत्तियों, फंक्शनलर्स का उपयोग कर रहे थे। मोनोलिथिक फ़ंक्शन जितना तेज़ नहीं है, लेकिन पढ़ने में बहुत आसान है। मैं इसे NRinC ++ नमूने के विपरीत जोड़ने की कोशिश करूंगा।
क्रिस्टियन एच।

क्या आपका मतलब था ^(((ht|f)tps?)\:\/\/)?(www\.)*[a-zA-Z0-9\-\.]+\.(com|edu|gov|mil|net|org|biz|info|name|museum|us|ca|uk)(\:[0-9]+)*(\/($|[a-zA-Z0-9\.\,\;\?\'\\\+&%\$#\=~_\-]+))*$? संख्यात्मक पते से अवगत रहें।
.ज़ाबेरा

कमोबेश मेरी बात: बहुत निचले स्तर के अमूर्त से निर्मित कुछ चीजें पढ़ना या सत्यापित करना आसान नहीं है। टिप्पणियाँ (और, बहुत दूर नहीं जाने के लिए, TESTS) उपयोगी हो सकता है, और एक बाधा नहीं। इसी समय, उपलब्ध उच्च स्तरीय सार का उपयोग न करना (: अल्फा:: संख्या: जहां उपलब्ध है) उच्च स्तर के सार का उपयोग करने की तुलना में, अच्छी टिप्पणियों के साथ भी समझना कठिन बना देता है।
क्रिस्टियन एच।

3
+1: "The need for comments is inversely proportional to the abstraction level of the code." बहुत सुंदर सब कुछ ठीक है।
गेरेट सेप

21

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

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

हालांकि उपरोक्त में से कोई भी टिप्पणियों का उपयोग अमान्य नहीं करता है। हम एक आदर्श दुनिया में नहीं रहते हैं, इसलिए जब किसी भी कारण से उपरोक्त में से कोई भी विफल हो जाता है, तो मेरे पास वापस गिरने के लिए कुछ टिप्पणियां होंगी।


18

मुझे लगता है कि आप जो कह रहे हैं, उसमें बहुत थोड़ा बहुत पढ़ रहे हैं। आपकी शिकायत के दो अलग-अलग हिस्से हैं:

(1) एक जटिल एल्गोरिथ्म या (2) एक वर्णनात्मक टिप्पणी के साथ कोड का एक लंबा और जटिल टुकड़ा समझाने के साथ क्या गलत है?

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

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

यह उस तरह का कोड है जिसके बारे में मार्टिन बात कर रहे हैं। और वह अध्याय के शीर्ष पर कर्निघन और प्लॉजर के उद्धरण के साथ आपके प्रश्न को संबोधित करता है:

बुरा कोड न लिखें - इसे फिर से लिखें।

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

और यह वही है जो मार्टिन कहता है:

टिप्पणियों का उचित उपयोग कोड में खुद को व्यक्त करने में हमारी विफलता के लिए क्षतिपूर्ति करना है ... टिप्पणियाँ हमेशा विफल होती हैं। हमें उनके पास होना चाहिए क्योंकि हम हमेशा उनके बिना खुद को व्यक्त करने का पता नहीं लगा सकते हैं, लेकिन उनका उपयोग उत्सव का कारण नहीं है।

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

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


3
अगर एक डेवलपर मैं केवल "बुराई फ्लोटिंग पॉइंट बिट स्तर हैकिंग" के साथ काम कर रहा था, तो तेजी से वर्ग-रूट एल्गोरिथ्म को समझाने के लिए - वे मेरे द्वारा बात कर रहे थे। जब तक वे कहीं अधिक उपयोगी एक संदर्भ शामिल मैं लंबे समय के लिए खुश था, हालांकि।
माइकल एंडरसन

8
मैं एक तरह से असहमत हूं - एक टिप्पणी जो यह बताती है कि कुछ बुरे काम बहुत जल्दी कैसे होते हैं। कुछ कोड को दिए जाने की संभावना है जिसे फिर से छुआ नहीं जाता है (अधिकांश कोड मुझे लगता है) तो एक टिप्पणी एक बड़ी रिफैक्टिंग की तुलना में बेहतर व्यावसायिक समाधान है, जो अक्सर बग्स का परिचय देता है (एक फिक्स के रूप में जो रिड्यूस-ऑन बग को मारता है वह अभी भी एक बग है)। पूरी तरह से समझने योग्य कोड की एक आदर्श दुनिया हमारे लिए उपलब्ध नहीं है।
gbjbaanb

2
@trysis haha, हाँ, लेकिन एक ऐसी दुनिया में जहाँ प्रोग्रामर ज़िम्मेदार हैं और व्यवसायी नहीं हैं, वे कभी भी जहाज नहीं चलाएंगे क्योंकि वे हमेशा के लिए सोने की परत चढ़ा रहे हैं।
gbjbaanb

4
@PatrickCollins लगभग सब कुछ जो मैंने वेब पर पढ़ा है वह पहली बार सही करने के बारे में है। लगभग कोई भी गड़बड़ को ठीक करने पर लेख लिखना नहीं चाहता है! भौतिकविदों का कहना है "एक आदर्श क्षेत्र दिया ..." Comp.Scientists का कहना है "एक ग्रीनफील्ड विकास दिया ..."
gbjbaanb

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

8

एक जटिल एल्गोरिथ्म या एक वर्णनात्मक टिप्पणी के साथ कोड का एक लंबा और जटिल टुकड़ा समझाने के साथ क्या गलत है?

ऐसा कुछ भी नहीं है। अपने काम का दस्तावेजीकरण करना अच्छा अभ्यास है।

उस ने कहा, आपके यहाँ झूठा द्वैतवाद है: साफ कोड लिखना बनाम दस्तावेज कोड लिखना - दोनों विरोध में नहीं हैं।

आपको जटिल कोड को सरल और अमूर्त कोड में ध्यान केंद्रित करना चाहिए, इसके बजाय "जटिल कोड ठीक है जब तक कि यह टिप्पणी नहीं की जाती है"।

आदर्श रूप से, आपका कोड सरल और प्रलेखित होना चाहिए ।

इस तरह, अन्य डेवलपर्स के बजाय (स्वयं सहित) यह पता लगाने के लिए लाइन द्वारा पूरी एल्गोरिथ्म लाइन को पढ़ने के लिए कि वह क्या करता है, वे बस मैत्रीपूर्ण अंग्रेजी में आपके द्वारा लिखी गई मित्रवत वर्णनात्मक टिप्पणी पढ़ सकते हैं।

सच। यही कारण है कि आपके सभी सार्वजनिक एपीआई एल्गोरिदम को प्रलेखन में समझाया जाना चाहिए।

तो एक आंशिक रूप से मानव-पठनीय प्रोग्रामिंग भाषा में लिखे गए कोड का एक जटिल टुकड़ा लिखने के बाद, अनुकूल और समझ में आने वाली अंग्रेजी में कोड के संचालन की व्याख्या करते हुए एक वर्णनात्मक और संक्षिप्त टिप्पणी क्यों नहीं जोड़नी चाहिए?

आदर्श रूप से, एक जटिल कोड लिखने के बाद आपको (एक विस्तृत सूची नहीं) चाहिए:

  • इसे एक मसौदा मानें (यानी इसे फिर से लिखने की योजना)
  • एल्गोरिथ्म प्रवेश बिंदु / इंटरफेस / भूमिका / आदि को औपचारिक करें (इंटरफ़ेस को एनालाइज और ऑप्टिमाइज़ करें, एब्स्ट्रैक्ट, डॉक्यूमेंट प्रीकॉन्डिशन्स, पोस्टकंडिशन और साइड इफेक्ट्स और डॉक्यूमेंट एरर मामलों को औपचारिक करें)।
  • परीक्षण लिखें
  • सफाई और परावर्तक

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

[...] कुछ एल्गोरिदम जटिल हैं। और इसलिए उन्हें समझना मुश्किल है जब उन्हें लाइन से पढ़ते हैं।

एपीआई क्या करता है यह जानने के लिए आपको कभी भी कार्यान्वयन को पढ़ने पर भरोसा नहीं करना चाहिए। जब आप ऐसा करते हैं, तो आप क्रियान्वयन के आधार पर क्लाइंट कोड लागू कर रहे हैं (इंटरफ़ेस के बजाय) और इसका मतलब है कि आपके मॉड्यूल युग्मन को पहले से ही नरक में गोली मार दी गई है, आप संभावित रूप से कोड के हर नई पंक्ति के साथ अनिर्धारित निर्भरता का परिचय दे रहे हैं जो आप लिखते हैं, और हैं पहले से ही तकनीकी ऋण जोड़ने।

क्या यह वास्तव में सामान्य ऑपरेशन के बारे में टिप्पणियों की कुछ पंक्तियों के साथ एक जटिल एल्गोरिथ्म की व्याख्या करना बुरा है?

नहीं - वह अच्छा है। टिप्पणियों की कुछ पंक्तियों को जोड़ना हालांकि पर्याप्त नहीं है।

एक टिप्पणी के साथ जटिल कोड की व्याख्या करने में क्या गलत है?

तथ्य यह है कि आपके पास जटिल कोड नहीं होना चाहिए, अगर इससे बचा जा सकता है।

जटिल कोड से बचने के लिए, अपने इंटरफेस को औपचारिक रूप दें, कार्यान्वयन पर खर्च की तुलना में एपीआई डिजाइन पर ~ 8 गुना अधिक खर्च करें (स्टीफनोव ने इंटरफ़ेस की तुलना में कम से कम 10x खर्च करने का सुझाव दिया, कार्यान्वयन के साथ), और ज्ञान के साथ एक परियोजना विकसित करने में जाएं आप एक परियोजना बना रहे हैं, न कि केवल कुछ एल्गोरिथ्म लिख रहे हैं।

एक परियोजना में एपीआई प्रलेखन, कार्यात्मक प्रलेखन, कोड / गुणवत्ता माप, परियोजना प्रबंधन और इतने पर शामिल हैं। इन प्रक्रियाओं में से कोई भी एक-बंद, तेज कदम नहीं हैं (वे सभी समय लेते हैं, पूर्वविवेक और योजना बनाने की आवश्यकता होती है, और उन्हें सभी की आवश्यकता होती है कि आप समय-समय पर उनके पास आते हैं और उन्हें विवरण के साथ संशोधित / पूरा करते हैं)।


3
"आपको एपीआई को लागू करने के लिए कार्यान्वयन को पढ़ने के लिए कभी भी भरोसा नहीं करना चाहिए।" कभी-कभी यह आपको एक अपस्ट्रीम द्वारा भड़काया जाता है जिसे आप उपयोग करने के लिए प्रतिबद्ध हैं। मेरे पास फॉर्म की टिप्पणियों के साथ एक विशेष रूप से असंतोषजनक परियोजना थी, "निम्नलिखित बदसूरत हीथ रॉबिन्सन कोड मौजूद है क्योंकि विक्रेता के दावे के बावजूद simpleAPI () इस हार्डवेयर पर ठीक से काम नहीं करता है"।
pjc50

6

अन्य डेवलपर्स के बजाय (स्वयं सहित) यह पता लगाने के लिए लाइन द्वारा पूरी एल्गोरिथ्म लाइन को पढ़ने के लिए कि वह क्या करता है, वे सिर्फ मैत्रीपूर्ण अंग्रेजी में आपके द्वारा लिखी गई मित्रवत वर्णनात्मक टिप्पणी पढ़ सकते हैं।

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

फ़ंक्शन में टिप्पणियाँ किसी के साथ-साथ कोड को पढ़ने के लिए हैं । इसलिए यदि आपके कोड में कुछ पंक्तियाँ हैं जिन्हें समझना मुश्किल है, और आप उन्हें समझना आसान नहीं बना सकते हैं, तो पाठक के लिए उन पंक्तियों के प्लेसहोल्डर के रूप में उपयोग करने के लिए एक टिप्पणी उपयोगी है। यह बहुत उपयोगी हो सकता है, जबकि पाठक सिर्फ सामान्य ज्ञान प्राप्त करने की कोशिश कर रहा है, लेकिन कुछ समस्याएं हैं:

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

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


5
टिप्पणियों के लिए एक उपयोगी स्थान: वैज्ञानिक कोड में, आप अक्सर गणना कर सकते हैं जो काफी जटिल हैं, जिसमें बहुत सारे चर शामिल हैं। प्रोग्रामर की पवित्रता के लिए, यह चर नामों को वास्तव में कम रखने के लिए समझ में आता है, इसलिए आप नामों के बजाय गणित को देख सकते हैं। लेकिन इससे पाठक को समझने में मुश्किल होती है। तो क्या हो रहा है (या बेहतर, एक जर्नल लेख या इसी तरह के समीकरण का एक संदर्भ) का एक संक्षिप्त विवरण, वास्तव में मददगार हो सकता है।
naught101

1
@ naught101: हाँ, विशेष रूप से उस पेपर के बाद से जिसका आप शायद एकल-अक्षर चर नामों का भी उपयोग कर रहे हैं। यह आमतौर पर यह देखना आसान है कि यदि आप समान नामों का उपयोग करते हैं तो कोड वास्तव में कागज का अनुसरण करता है, लेकिन यह कोड के लक्ष्य के साथ आत्म-व्याख्यात्मक है (यह इसके बजाय पेपर द्वारा समझाया गया है )। इस मामले में, एक टिप्पणी जहां प्रत्येक नाम को परिभाषित किया गया है, यह कहते हुए कि वास्तव में इसका क्या अर्थ है, सार्थक नामों के लिए विकल्प।
स्टीव जेसोप

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

1
@FlorianF: पारंपरिक प्रतिक्रिया यह है कि चर और फ़ंक्शन नाम मोटे तौर पर संकेत देते हैं कि कोड के बारे में क्या है, और इसलिए आपको उन चीजों पर ध्यान देना चाहिए जो निश्चित रूप से आपके बारे में नहीं देख रहे हैं। मैं आपके साथ सहमत हूं कि यह हमेशा सफल नहीं होता है, लेकिन मैं इतनी दृढ़ता से सहमत नहीं हूं कि मुझे लगता है कि सभी कोड को खोज या स्किम-रीडिंग की सहायता के लिए टिप्पणी करने की आवश्यकता है। लेकिन आप सही हैं, यह एक ऐसा मामला है जहां कोई आपके कोड (सॉर्ट) को पढ़ रहा है और वैध रूप से इसे समझने की आवश्यकता नहीं है।
स्टीव जेसोप

2
@Snowman लोग चर नामों के साथ ऐसा कर सकते हैं। मैंने वह कोड देखा है, जहां चर सूचीऑफ एपल्स में केले की सूची थी। किसी ने सेब की सूची को संसाधित करने वाले कोड की प्रतिलिपि बनाई और परिवर्तनशील नामों को परेशान किए बिना केले के लिए इसे अनुकूलित किया।
फ्लोरियन एफ

5

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

// This code implements the algorithm described in requirements document 239.

या यहां तक ​​कि बस

void doPRD239Algorithm() { ...

निश्चित रूप से नाम वाले MatchStringKnuthMorrisPrattया encryptAESया कार्यों से लोग खुश हैं partitionBSP। अधिक अस्पष्ट नाम एक टिप्पणी में समझाने लायक हैं। आप बिब्लियोग्राफिक डेटा और एक पेपर के लिंक को भी जोड़ सकते हैं जिसे आपने एल्गोरिथ्म से लागू किया है।

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

कोड की एक और श्रेणी है जो नौकरशाही के रूप में इतनी एल्गोरिथम नहीं है। आपको किसी अन्य सिस्टम के लिए पैरामीटर सेट करने की आवश्यकता है, या किसी और के बग के साथ इंटरॉपर्ट करें:

/* Configure the beam controller and turn on the laser.
The sequence is timing-critical and this code must run with interrupts disabled.
Note that the constant 0xef45ab87 differs from the vendor documentation; the vendor
is wrong in this case.
Some of these operations write the same value multiple times. Do not attempt
to optimise this code by removing seemingly redundant operations.
*/

2
मैं उनके आंतरिक एल्गोरिथ्म के बाद कार्यों / विधियों के नामकरण के खिलाफ तर्क दूंगा, ज्यादातर समय जिस विधि का उपयोग किया जाता है वह एक आंतरिक चिंता का विषय होना चाहिए, हर तरह से आपके द्वारा उपयोग की गई विधि के साथ अपने फ़ंक्शन के शीर्ष को दस्तावेज़ित करें, लेकिन इसे कॉल न करें doPRD239Algorithmजो मुझे बताता है एल्गोरिथ्म को देखने के बिना फ़ंक्शन के बारे में कुछ भी नहीं, कारण MatchStringKnuthMorrisPrattऔर encryptAESकार्य यह है कि वे जो कुछ भी करते हैं उसके विवरण से शुरू होता है, फिर कार्यप्रणाली के विवरण के साथ।
स्कगर

5

मैं भूल जाते हैं जहां मैंने इसे पढ़ा लेकिन वहाँ है कि आपके कोड में दिखाई देनी चाहिए और एक टिप्पणी के रूप में क्या दिखाई देनी चाहिए के बीच एक तेज और स्पष्ट रेखा।

मेरा मानना ​​है कि आपको अपने इरादे पर टिप्पणी करनी चाहिए , न कि आपके एल्गोरिथ्म पर । यानी आप जो करना चाहते हैं उस पर टिप्पणी करें, न कि आप क्या करते हैं

उदाहरण के लिए:

// The getter.
public <V> V get(final K key, Class<V> type) {
  // Has it run yet?
  Future<Object> f = multitons.get(key);
  if (f == null) {
    // No! Make the task that runs it.
    FutureTask<Object> ft = new FutureTask<Object>(
            new Callable() {

              public Object call() throws Exception {
                // Only do the create when called to do so.
                return key.create();
              }

            });
    // Only put if not there.
    f = multitons.putIfAbsent(key, ft);
    if (f == null) {
      // We replaced null so we successfully put. We were first!
      f = ft;
      // Initiate the task.
      ft.run();
    }
  }
  try {
    /**
     * If code gets here and hangs due to f.status = 0 (FutureTask.NEW)
     * then you are trying to get from your Multiton in your creator.
     *
     * Cannot check for that without unnecessarily complex code.
     *
     * Perhaps could use get with timeout.
     */
    // Cast here to force the right type.
    return (V) f.get();
  } catch (Exception ex) {
    // Hide exceptions without discarding them.
    throw Throwables.asRuntimeException(ex);
  }
}

यहां राज्य के लिए क्या हर कदम प्रदर्शन का कोई प्रयास नहीं सब यह कहा गया कि यह है है, माना जाता करने के लिए।

पुनश्च: मुझे पता चला कि मैं जिस स्रोत का जिक्र कर रहा था - कोडिंग हॉरर: कोड टेल यू यू, कमेंट्स टेल यू क्यों


8
पहली टिप्पणी: क्या यह अभी तक चला है? अभी तक क्या चला है? अन्य टिप्पणियों के लिए भी। किसी को पता नहीं है कि कोड क्या करता है, यह बेकार है।
gnasher729

1
@ gnasher729 - संदर्भ से बाहर लिया गया लगभग कोई भी टिप्पणी बेकार होगी - यह कोड टिप्पणियों को जोड़ने का एक प्रदर्शन है जो वर्णन करने का प्रयास करने के बजाय इरादा दर्शाता है । मुझे खेद है कि यह आपके लिए कुछ नहीं करता है।
OldCurmudgeon

2
उस कोड के अनुरक्षक के पास कोई संदर्भ नहीं होगा। यह पता लगाना विशेष रूप से मुश्किल नहीं है कि कोड क्या करता है, लेकिन टिप्पणियां मदद नहीं कर रही हैं। यदि आप टिप्पणी लिखते हैं, तो अपना समय लें और जब आप उन्हें लिखते हैं तब ध्यान केंद्रित करें।
gnasher729

BTW - क्या यह अभी तक चलाया गया है, टिप्पणी का जिक्र है Futureऔर इंगित करता है कि get()जाँच के बाद जाँच करता है कि nullक्या Futureपहले ही चलाया जा चुका है - प्रक्रिया के बजाय इरादे को सही ढंग से दर्ज करना ।
OldCurmudgeon

1
@OldCurmudgeon: आपका उत्तर काफी करीब है जो मैं सोच रहा था, कि मैं इस टिप्पणी को आपके बिंदु के उदाहरण के रूप में जोड़ूंगा। जबकि एक टिप्पणी को स्वच्छ कोड की व्याख्या करने की आवश्यकता नहीं है, एक टिप्पणी यह ​​समझाने के लिए अच्छा है कि कोडिंग को एक दिन में क्यों किया गया था। मेरे सीमित अनुभव में, कोड को लागू करने के लिए डेटा सेट की idiosyncracies की व्याख्या करने के लिए टिप्पणियां अक्सर उपयोगी होती हैं, या कोड को लागू करने के लिए व्यापार नियमों का मतलब है। बग को ठीक करने के लिए जो टिप्पणी कोड जोड़ा गया है, वह एक अच्छा उदाहरण है, यदि वह बग हुआ है क्योंकि डेटा के बारे में एक धारणा गलत थी।
रान्डेल स्टीवर्ट

4

लेकिन हम सभी जानते हैं कि यह पर्याप्त नहीं है।

वास्तव में? कब से?

अच्छे नामों के साथ अच्छी तरह से डिज़ाइन किया गया कोड अधिकांश मामलों में पर्याप्त से अधिक है। टिप्पणियों का उपयोग करने के खिलाफ तर्क अच्छी तरह से ज्ञात और प्रलेखित हैं (जैसा कि आप देखें)।

लेकिन ये दिशा-निर्देश हैं (जैसे कुछ और)। दुर्लभ स्थिति में (मेरे अनुभव में, हर 2 साल में लगभग एक बार) जहां चीजें बदतर होती हैं जब छोटे सुपाठ्य कार्यों (प्रदर्शन या सामंजस्य की आवश्यकता के कारण) में रिफैक्ट हो जाते हैं, तो आगे बढ़ें - कुछ लंबी टिप्पणी में यह बताते हुए कि वास्तव में क्या है (और आप सर्वोत्तम प्रथाओं का उल्लंघन क्यों कर रहे हैं) कर रहे हैं।


7
मुझे पता है कि यह पर्याप्त नहीं है।
फ्लोरियन एफ

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

3
मैं कभी भी अन्य लोगों के कोड को समझने की कोशिश कर रहा हूं, जिनकी मैं चाहता हूं कि हर दो साल में एक बार से अधिक कुछ टिप्पणियां जोड़ी जाएं।
ओगरे Psalm33

@ OgrePsalm33 - क्या उनके पास छोटे तरीके हैं और अच्छे नामों का उपयोग करते हैं? खराब कोड बुरा है, टिप्पणियों की परवाह किए बिना।
तेलस्टिन

2
@Telastyn दुर्भाग्य से, जब एक बड़े कोड आधार पर काम करते हैं, तो "छोटे" तरीके और "अच्छे" नाम प्रत्येक डेवलपर के लिए व्यक्तिपरक होते हैं (इसलिए उस मामले के लिए एक अच्छी टिप्पणी है)। 7 साल के लिए फ़्लारबिगन ग्राफिकल प्रोसेसिंग एल्गोरिदम कोड लिखने वाला एक डेवलपर, उसके और समान डेवलपर्स के लिए पूरी तरह से कुछ स्पष्ट लिख सकता है, लेकिन नए आदमी के लिए गुप्त होगा जो पिछले 4 वर्षों में पेरबियन ग्रिड इंफ्रास्ट्रक्चर कोड विकसित कर रहा है। फिर, 2 सप्ताह बाद, फ़्लार्बिगन विशेषज्ञ क्विट करता है।
ओगरे Psalm33

2

कोड का मुख्य उद्देश्य कंप्यूटर को कुछ करने की आज्ञा देना है, इसलिए एक अच्छी टिप्पणी कभी भी अच्छे कोड का विकल्प नहीं है क्योंकि टिप्पणियों को निष्पादित नहीं किया जा सकता है।

कहा जा रहा है, स्रोत में टिप्पणी अन्य प्रोग्रामर (स्वयं सहित) के लिए प्रलेखन का एक रूप है। यदि टिप्पणी हर कदम पर कोड क्या कर रही है की तुलना में अधिक सार मुद्दों के बारे में हैं, तो आप औसत से बेहतर कर रहे हैं। अमूर्त का वह स्तर आपके द्वारा उपयोग किए जा रहे टूल के साथ भिन्न होता है। असेंबली लैंग्वेज रूटीन वाली टिप्पणियों में आम तौर पर "एब्स्ट्रक्शन" का स्तर कम होता है, उदाहरण के लिए, यह एपीएल A←0⋄A⊣{2⊤⍵:1+3×⍵⋄⍵÷2}⍣{⍺=A+←1}⎕। मुझे लगता है कि शायद उस समस्या के बारे में एक टिप्पणी होगी जो इसे हल करने का इरादा है, हम्म?


2

यदि कोड तुच्छ है, तो उसे व्याख्यात्मक टिप्पणी की आवश्यकता नहीं है। यदि कोड गैर-तुच्छ है, तो व्याख्यात्मक टिप्पणी की संभावना भी गैर-तुच्छ होगी।

अब, गैर-तुच्छ प्राकृतिक भाषा के साथ परेशानी यह है कि हम में से कई इसे पढ़ने या इसे लिखने में बहुत अच्छे नहीं हैं। मुझे यकीन है कि आपके लिखित संचार कौशल उत्कृष्ट हैं, लेकिन फिर भी लिखित भाषा की कम समझ वाला कोई व्यक्ति आपके शब्दों को गलत समझ सकता है।

यदि आप प्राकृतिक भाषा को लिखने की बहुत कोशिश करते हैं जिसे गलत नहीं समझा जा सकता है तो आप एक कानूनी दस्तावेज की तरह कुछ खत्म कर सकते हैं (और जैसा कि हम सभी जानते हैं कि वे अधिक क्रियात्मक हैं और कोड की तुलना में समझना मुश्किल है)।

कोड आपके तर्क का सबसे संक्षिप्त विवरण होना चाहिए, और आपके कोड के अर्थ के बारे में बहुत बहस नहीं होनी चाहिए क्योंकि आपके कंपाइलर और प्लेटफ़ॉर्म का अंतिम कहना है।

व्यक्तिगत रूप से मैं यह नहीं कहूंगा कि आपको कभी टिप्पणी नहीं लिखनी चाहिए। केवल आपको यह विचार करना चाहिए कि आपके कोड को टिप्पणी की आवश्यकता क्यों है, और आप इसे कैसे ठीक कर सकते हैं। यहाँ उत्तर में यह एक सामान्य विषय लगता है।


वास्तव में मैं जो सोच रहा था जब मैं इस कथन से असहमत था "एक मानव अंग्रेजी के एक टुकड़े को बहुत तेजी से समझ सकता है कि वह / वह एक ही अर्थ के साथ कोड का एक टुकड़ा समझ सकता है (जब तक कि ऑपरेशन तुच्छ नहीं है)" कोड है हमेशा कम अस्पष्ट और अधिक संक्षिप्त।
स्टीफनबेयर

0

एक बिंदु का अभी तक उल्लेख नहीं किया गया है कि कभी-कभी यह टिप्पणी करना कि कोड का एक टुकड़ा उन मामलों में मददगार हो सकता है जहां एक भाषा कई उद्देश्यों के लिए एक विशेष वाक्यविन्यास का उपयोग करती है। उदाहरण के लिए, यह मानते हुए कि सभी चर प्रकार के हैं float, विचार करें:

f1 = (float)(f2+f3); // Force result to be rounded to single precision
f4 = f1-f2;

स्पष्ट रूप से कास्टिंग floatकरने floatका प्रभाव परिणाम को एकल परिशुद्धता पर गोल करने के लिए मजबूर करना है; इस प्रकार टिप्पणी को केवल यह कहते हुए देखा जा सकता है कि कोड क्या करता है। दूसरी ओर, उस कोड की तुलना करें:

thing.someFloatProperty = (float)(f2*0.1); // Divide by ten

यहां, कलाकारों का उद्देश्य कंपाइलर को सटीक कंप्यूटिंग (f2 / 10) के सबसे कुशल तरीके से रोकने के लिए है [यह 0.1f से गुणा करने पर अधिक सटीक है, और अधिकांश मशीनों पर यह 10.0f से विभाजित होने की तुलना में तेज़ है]।

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


मुझे यकीन नहीं है कि जे। रैंडम प्रोग्रामर, दूसरे उदाहरण को देखते हुए, महसूस करेंगे कि निरंतर 0.1 अच्छे कारण के लिए लिखा जाता है, बजाय इसके कि मूल प्रोग्रामर 'f' लिखना भूल गया।
डेविड के

विशेष रूप से डिबगिंग के दौरान, आप कभी भी यह नहीं मानते हैं कि कुछ भी एक अच्छे कारण के लिए किया गया है।
gnasher729

@DavidK: मेरे दूसरे उदाहरण कोड का उद्देश्य कोड के पहले टुकड़े के साथ इसके विपरीत था। कोड के दूसरे भाग में, प्रोग्रामर का इरादा संभवतः someFloatPropertyसबसे सटीक प्रतिनिधित्व रखने का है f2/10जो यह कर सकता है; दूसरी कास्ट का प्राथमिक उद्देश्य इस प्रकार कोड को संकलित करना है । पहले उदाहरण में, हालांकि, कास्ट स्पष्ट रूप से अपने सामान्य उद्देश्य (एक संकलन-समय प्रकार को दूसरे में बदलना) के लिए आवश्यक नहीं है क्योंकि ऑपरेंड पहले से ही है float। टिप्पणी यह ​​स्पष्ट करने के लिए कार्य करती है कि कलाकारों को एक माध्यमिक उद्देश्य (गोलाई) के लिए आवश्यक है।
सुपरकैट

मैं इस धारणा से सहमत हूं कि आपको (float)दूसरे उदाहरण में कलाकारों के बारे में कोई टिप्पणी करने की आवश्यकता नहीं है । प्रश्न शाब्दिक स्थिरांक के बारे में है 0.1। आपने समझाया (पाठ के अगले पैराग्राफ में) हम क्यों लिखेंगे 0.1: "यह 0.1 एफ द्वारा गुणा से अधिक सटीक है।" मैं सुझाव दे रहा हूं कि वे शब्द हैं जो टिप्पणी में होने चाहिए।
डेविड के।

@ डेविड: मैं निश्चित रूप से टिप्पणी को शामिल करूंगा अगर मुझे पता था कि 0.1 एफ अस्वीकार्य रूप से अभेद्य होगा, और 0.1 एफ का उपयोग करेगा यदि मुझे पता था कि परिशुद्धता का नुकसान स्वीकार्य होगा और वास्तव में 0.1 एफ भौतिक रूप से 0.1 से तेज होगा । अगर मैं उन चीजों में से किसी को भी सच नहीं जानता हूं, तो मेरी कोडिंग की आदत doubleकांस्टेंट या इंटरमीडिएट गणनाओं के लिए उपयोग की जाएगी, जिसका मान संभव नहीं हो सकता है float[हालांकि उन भाषाओं में जिन्हें स्पष्ट डबल-टू-फ्लोट कास्ट कष्टप्रद होने की आवश्यकता है, आलस्य floatगति के लिए नहीं बल्कि झुंझलाहट को कम करने के लिए स्थिरांक का उपयोग करने के लिए धक्का हो सकता है ]।
सुपरकाट

-1

टिप्पणियाँ जो बताती हैं कि कोड क्या करता है दोहराव का एक रूप है। यदि आप कोड बदलते हैं और फिर टिप्पणियों को अपडेट करना भूल जाते हैं तो यह भ्रम पैदा कर सकता है। मैं यह नहीं कह रहा हूं कि उनका उपयोग न करें, बस उनका उपयोग विवेकपूर्ण तरीके से करें। मैं अंकल बॉब मैक्सिम की सदस्यता लेता हूं: "केवल टिप्पणी करें कि कोड क्या कह सकता है"।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.