स्रोत फ़ाइल की शुरुआत में एक टिप्पणी में बग संख्या डालने के लिए अच्छा विचार है? [बन्द है]

Question

क्या हेडर कमेंट के अंदर ही फाइल में बग नंबर डालना एक अच्छा अभ्यास है?

टिप्पणियां कुछ इस तरह दिखेंगी:

 MODIFIED    (MM/DD/YY)
 abc 01/21/14 - Bug 17452317 - npe in drill across in dashboard edit mode

 cde 01/17/14 - Bug 2314558  - some other error description

यह मददगार लगता है, लेकिन क्या इसे बुरा व्यवहार माना जाता है?

Comments

सवाल मैं पूछ रहा हूँ "क्या आप एम्बेडेड बग संख्याओं के साथ कर सकते हैं जो आप पहले से ही अपने बग डेटाबेस के साथ नहीं कर सकते हैं?" मैं किसी भी वास्तविक उपयोग के मामलों के बारे में नहीं सोच सकता।

— एम। डडले

संबंधित: stackoverflow.com/questions/123936/…

— ब्रायन

@JensG यही कारण है कि आप इसे प्रतिबद्ध संदेश में डालते हैं, और logफ़ाइल पर आपको बहुत ही सटीक चीज़ देगा, लेकिन फ़ाइल को बंद किए बिना ...

— इज़ाकटा

@ जेन्स जी और जब आपने किसी विशेष फ़ाइल पर स्कोर या सैकड़ों दोषों को ठीक किया है? स्पष्ट उत्तर यह है कि आप समय-समय पर बासी आईडी को हटा सकते हैं, लेकिन फिर आप वीसी लॉग को वापस करने के लिए ...

— dmckee

यह प्रश्न Ars Technica लेख का विषय है। क्या हमें स्रोत फ़ाइल के हेडर में बग्स को सूचीबद्ध करना चाहिए? (इस सवाल के पोस्ट होने के 15 दिन बाद प्रकाशित)।

— पीटर मोर्टेंसन

Answer 1

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

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

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

Comments

"और यदि आप एक आधुनिक संस्करण नियंत्रण प्रणाली का उपयोग कर रहे हैं जो परिवर्तन सेट का समर्थन करता है, तो यह वास्तव में परिवर्तनों के बारे में जानकारी खो रहा है।" - क्या आप कृपया विस्तार से बता सकते हैं?

— Geek

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

— थॉमस ओवेन्स

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

— 17 की 26

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

— क्रंचर

@ 17of26 - मुझे लगता है कि आप पुराने कीड़े / मुद्दों को नए से जोड़ सकते हैं, अगर "पुराने मुद्दे ट्रैकर बग 1234" जैसी टिप्पणी के अलावा कोई अन्य तंत्र नहीं है।

— केनी एविट

Answer 2

भविष्य के प्रोग्रामर के लिए चेतावनी के एक भाग के रूप में, मैं ऐसा करने वाला बिल्कुल एक मामला है: " foo()सीधे यहां फ़ंक्शन न करें ; इससे बग # 1234 हो गया है, अर्थात् ...", और फिर एक संक्षिप्त विवरण बग इस प्रकार है।

और अगर कोड इस तरह से बदल गया है कि foo()सीधे कॉल करने का कोई प्रलोभन नहीं है , तो उस टिप्पणी को हटा दें। यह केवल जलन और कोड को उड़ा देगा।

Comments

शायद मैं थोड़ा सख्त हूँ, लेकिन अगर foo()इसे सीधे नहीं बुलाया जाना चाहिए, तो कोड को इस तरह से संरचित किया जाना चाहिए कि यह नहीं हो सकता है।

— 14

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

— रेम

Answer 3

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

केवल एक ही उल्टा मैं यह समझ सकता हूं कि आप संस्करण नियंत्रण तक पहुंच के बिना स्रोत इतिहास को फिर से बना सकते हैं, जैसे कि प्रिंटआउट का अध्ययन करते समय। लेकिन बहुत कम लोग सॉफ्टवेयर विकास की जटिलताओं का पालन करने के लिए पर्याप्त सक्षम हैं, जबकि एक साथ संस्करण नियंत्रण को समझने में असमर्थ हैं।

Comments

आपको लगता है कि वास्तव में कितने कीड़े एक फ़ाइल में संभव हैं और यदि ऐसा है तो फिर से लिखना के लिए कई बार संभव है।

— एंडी

Answer 4

नहीं।

इससे पहले कि लोग एक संस्करण नियंत्रण प्रणाली का उपयोग करते थे (यानी जब स्रोत कोड सिर्फ ज़िप में बैकअप था)।

Comments

जो एक प्रकार का संस्करण नियंत्रण प्रणाली थी (और मैंने एक सॉफ्टवेयर सॉफ़्टवेयर हाउस में 2006 से पहले ही परिचालन में उपयोग किया है, और इसमें कोई संदेह नहीं है कि आज कहीं भी उपयोग किया जाता है)।

— 14

@jwenting मैंने इस साइट पर ऐसे लोगों से सवाल पूछे हैं जो दुर्भाग्यपूर्ण हैं कि वर्तमान में दुकानों में काम कर रहे हैं, जहां यह वर्तमान अभ्यास है :-(

— कार्सन63000

हम एक महान स्रोत नियंत्रण प्रणाली का उपयोग करते हैं। कोड में जाँच करने पर कोई भी मुझे टिप्पणी नहीं देता है। <shrug> मैं कुछ चीजों पर टिप्पणी करता हूं (जैसे PLSQL जो हमेशा SCM द्वारा ट्रैक नहीं किया जाता है)। मैं अपने कोड को समझाने के लिए टिप्पणी करता हूं, लेकिन कभी भी इसे विशेष रूप से बग के लिए वापस टाई नहीं करता, लेकिन मैं हमेशा एससीएम में कीड़े का संदर्भ देता हूं जब मैं जांच करता हूं। उम्मीद है कि अंततः कोई इसकी सराहना करेगा।

— 23

Answer 5

यह, IMHO, एक बहुत बुरा विचार है। संशोधन संख्या 100 के बाद, आपके पास 90% टिप्पणियां और 10% कोड होगा। मैं इसे उतना साफ और पठनीय नहीं मानूंगा।

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

Answer 6

मैं देखता हूं कि हर कोई इस विचार का विरोधी है और लोगों को ऐसा करने का ऐतिहासिक कारण (पूर्व स्रोत नियंत्रण युग) दिया।

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

हां, यह कोड को बंद कर देता है, लेकिन यह इस कारण को खोजने में मदद करता है कि उस कोड का टुकड़ा क्यों है।

Comments

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

— 20

उस जानकारी को प्राप्त करने के लिए अक्सर एक और तरीका है (जिस परियोजना पर मैं काम कर रहा हूं, वह right click > Team > Show Annotationsवर्तमान फ़ाइल का गिट दोष प्राप्त करना होगा ), लेकिन अंतर यह है कि टिप्पणियों के साथ खोज योग्यता है - वे आप पर कूद सकते हैं - और एनोटेशन के साथ, आपको सचेत रूप से उनकी तलाश में जाने का फैसला करना होगा।

— डेविड कॉनरेड

सोचें, निर्णय लें, क्लिक करें, क्लिक करें, क्लिक करें, स्क्रॉल करें। इसलिए मैंने कहा "कोड में कैशिंग"। अगर यह वहां है, तो मैं इसे देखता हूं।

— जेनसेग

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

— जेफरी हेंटिन

Answer 7

जोएल परीक्षण में एक बिंदु है

क्या आपके पास बग डेटाबेस है?

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

Comments

उदाहरण को प्रश्न में देखें - टिप्पणियां बग डेटाबेस का संदर्भ

— देंगी

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

— पियरे अरलाउड

Answer 8

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

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

एक बार जब आप इसे व्यवहार में लाते हैं, तो बनाई गई आदतें सभी के लिए काम करने के लिए कोड आधार को आसान बना देती हैं।

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

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

Answer 9

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

Answer 10

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

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

व्यक्तिगत रूप से, मुझे लगता है कि उपकरण और इन-कोड लॉग दोनों के लिए जगह है।

Answer 11

मुझे पता है कि Git ऐसा नहीं करता है और इसका सरल उत्तर है "पृथ्वी पर यह वहाँ क्यों जाएगा ?"

यह सामान्य रूप से कम मॉड्यूलर डिजाइन है। इस समाधान के तहत, अब फ़ाइलें सामग्री और मेटा-डेटा के बीच कुछ मिश्रण हैं। Amazon S3 फ़ाइलों को संग्रहीत करने के लिए एक सेवा का एक और उदाहरण है जो YAML फ्रंट-मैटर या फ़ाइलों की तरह नहीं जोड़ता है ।

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

Answer 12

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

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

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

यदि आप इस विषय पर एक अच्छा पढ़ने की तलाश कर रहे हैं, तो मैं स्वच्छ संहिता के अध्याय चार की सिफारिश करता हूं ।

Comments

कॉपीराइट सूचनाएँ भी हैं (थोड़ा अतिरेक से) कर्मचारियों को इस बात पर ध्यान दें कि फाइल नियोक्ता की है। और शायद अवैध बंटवारे (यहां तक कि कर्मचारियों द्वारा), कितने लोगों को लगता है कि अगर वहाँ है कि कॉपीराइट तभी लागू होता प्रतीत द्वारा पहचानने हतोत्साहित है एक नोटिस।

— बेरंड जेन्ड्रीसेक

Answer 13

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

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

इसी तरह, ऐसे वातावरण में काम करते समय जहां कई (फीचर) शाखाएं शामिल होती हैं, यह तीसरे व्यक्ति (बिल्ड मास्टर) के लिए यह पहचानना आसान बनाता है कि संभावित संघर्षों को हल करने के लिए क्या किया जाए।

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

Comments

सवाल स्रोत फ़ाइल की शुरुआत में टिप्पणी के बारे में है, कॉपीराइट संदेश के ठीक बाद - इसका

— संकरे

यहाँ सभी उत्तर केवल उसी के बारे में बात कर रहे हैं। अगर मैं पूरी कक्षा की फ़ाइल (रीगॉर या फ़ॉरमेट फ़िक्सिंग) में महत्वपूर्ण परिवर्तन करता हूँ, तो क्या मैं वर्ग फ़ाइल को स्कोप के रूप में टिप्पणी नहीं करूँगा?

— स्टिंगजाइक

Answer 14

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

फ़ंक्शन सारांश में जानकारी जोड़ने के लिए यह आम बात हुआ करती थी जब हमें कोड से रिलीज़ नोट्स बनाने के लिए बाहरी उपकरणों (जावदोक्स) पर भरोसा करना पड़ता था। यह आधुनिक संस्करण नियंत्रण उपकरणों के साथ ज्यादातर बेकार या निरर्थक है।

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

Answer 15

मैं निश्चित रूप से इस तरह की जानकारी को फ़ाइल के शुरू में नहीं डालूंगा - आमतौर पर ऐसी चीज टिकट प्रणाली में होती है।

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

Comments

यह पहले से ही पहले जवाब में पोस्ट किया गया है के लिए पर्याप्त मूल्य जोड़ने के लिए प्रतीत नहीं होता है

— gnat

Answer 16

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

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

संक्षेप में, ये सूचियां सबसे बेकार हैं और अंतरिक्ष के सबसे बड़े पैमाने पर अराजक कचरे में से हैं, जो कोड को खोजने और खोजने के लिए कठिन बनाता है।