क्या आप अपने कोड में बग फिक्स पर विशेष टिप्पणियों का उपयोग करते हैं?


16

मेरे साथियों में से कुछ उदाहरण के लिए, उनके बग फिक्स पर विशेष टिप्पणी का उपयोग करें:

// 2008-09-23 John Doe - bug 12345 
// <short description> 

यह आप मतलब?
क्या आप किसी विशेष तरीके से बग फिक्स को टिप्पणी करते हैं?

कृपया मुझे बताएं।

33

मैं इस तरह की टिप्पणियों में नहीं डालता, स्रोत नियंत्रण प्रणाली पहले से ही उस इतिहास को बनाए रखती है और मैं पहले से ही एक फ़ाइल के इतिहास को लॉग इन करने में सक्षम हूं।

मैं टिप्पणियों में डालता हूं जो वर्णन करता है कि कुछ गैर-स्पष्ट क्यों किया जा रहा है। तो अगर बग फिक्स कोड को कम अनुमानित और स्पष्ट बनाता है, तो मैं समझाता हूं कि क्यों।


4

केवल अगर समाधान विशेष रूप से चालाक या समझने में मुश्किल था।


3

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


15

समय के साथ ये जमा हो सकते हैं और अव्यवस्था जोड़ सकते हैं। कोड को स्पष्ट करना बेहतर है, संबंधित गॉथस के लिए कोई टिप्पणी जोड़ें जो स्पष्ट नहीं हो सकता है और ट्रैकिंग सिस्टम और भंडार में बग विवरण रख सकता है।

  0

आप पूरी तरह से सही हैं। मुझे हमारे कोड में एक विधि याद है, जिसमें केवल बग फिक्स शामिल हैं (ऊपर वर्णित टिप्पणियों के प्रकार के बारे में)! 23 sep. 082008-09-23 21:23:31

  0

एक ट्रैकिंग सिस्टम भंडार क्या है? 27 sep. 112011-09-27 16:15:32

  0

जब मैंने "ट्रैकिंग सिस्टम और रिपोजिटरी" का उल्लेख किया था, तो मैं दो चीजों का जिक्र कर रहा था। एक, एक बग ट्रैकिंग सिस्टम, जैसे बगजिला या जेरा जहां आप किसी मुद्दे के बारे में टिप्पणी डाल सकते हैं। दूसरा, एक स्रोत कोड भंडार जैसे एसवीएन या गिट जहां आप टिप्पणियों के साथ टिप्पणियां डाल सकते हैं। 29 sep. 112011-09-29 19:40:22


2

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


0

लोगों का पता लगाने के विशिष्ट टिप्पणी हम DKBUGBUG का उपयोग करें - जो डेविड केली का ठीक और समीक्षक का मतलब है आसानी से पहचान, बेशक हम तिथि और अन्य VSTS बग ट्रैकिंग नंबर आदि इस के साथ जोड़ देगा कर सकते हैं।


6

मैं वास्तविक स्रोत में टिप्पणी नहीं करता क्योंकि यह अद्यतित रहना मुश्किल हो सकता है। हालांकि मैं अपने स्रोत नियंत्रण लॉग और समस्या ट्रैकर में टिप्पणियां जोड़ने डालता हूं। जैसे मैं पेर्सफोर्स में ऐसा कुछ कर सकता हूं:

[बग-आईडी] xyz संवाद के साथ समस्या। एबीसी को आकार देने वाला कोड और अब बाद में आरंभ करें।

तब मेरे समस्या ट्रैकर में मैं की तरह कुछ करना होगा:

परिवर्तन सूची में फिक्स्ड 1234.

एबीसी के लिए कोड आकार ले जाया गया है और अब आरंभ बाद में।

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


4

मैं आमतौर पर अपना नाम, मेरा ई-मेल पता और तिथि जो मैंने बदलता है उसके संक्षिप्त विवरण के साथ जोड़ता हूं, ऐसा इसलिए है क्योंकि सलाहकार के रूप में मैं अक्सर अन्य लोगों के कोड को ठीक करता हूं।

// Glenn F. Henriksen (<[email protected]) - 2008-09-23 
// <Short description> 

इस तरह कोड मालिकों, या लोगों ने मुझे बाद में आ रहा है, यह पता लगाने कर सकते हैं कि क्या हुआ और अगर वे करने के लिए है कि वे मेरे साथ संपर्क में प्राप्त कर सकते हैं।

+2

Sourcecontrol इस सारी जानकारी का ट्रैक रखता है। और, चूंकि आप परामर्शदाता हैं, इसलिए आपको स्रोत नियंत्रण प्रणाली का उपयोग करने के लिए अपने क्लाइंट से परामर्श लेना चाहिए। 02 feb. 112011-02-02 08:13:01

+1

मैं परामर्श करता हूं, लेकिन कभी-कभी मेरी सलाह बधिर कानों पर पड़ती है। यदि ग्राहक के पास स्रोत नियंत्रण है तो मैंने कभी भी इन टिप्पणियों को नहीं रखा है, तो यह केवल अतिरिक्त शोर है। 05 apr. 112011-04-05 19:46:22

  0

स्रोत नियंत्रण प्रणाली क्या है? 27 sep. 112011-09-27 16:16:40

  0

@ मार्कक्रामर ग्राहक पर निर्भर करता है। माइक्रोसॉफ्ट टीम फाउंडेशन सबसे आम है। गिट भी थोड़ा सा प्रयोग किया जाता है। हर बार मैं विजुअल सोर्ससेफ में ठोकर खा रहा हूं ... 10 oct. 112011-10-10 13:16:19


1

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


4

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

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


0

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

इस के बजाय:

// उपयोगी टिप्पणी अगले करने के लिए:

// $ DATE के $ name $ TICKET // अगले गरीब आत्मा के लिए उपयोगी टिप्पणी

मैं यह कर होगा गरीब आत्मा


2

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

// <date> [my name] - Bug xxxxx happens when the foo parameter is null, but 
// some customers want the behavior. Jump through some hoops to find a default value. 

अन्य मामलों में स्रोत नियंत्रण संदेश के लिए प्रतिबद्ध है कि मैं क्या करने के लिए उपयोग है परिवर्तन को एनोटेट करें।


1

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

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

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


2

टिप्पणी की यह शैली एक बहु-डेवलपर वातावरण में बेहद मूल्यवान है जहां डेवलपर्स (जैसे - हर जगह) में कई प्रकार के कौशल और/या व्यावसायिक ज्ञान हैं।

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

ओह, और "मैं सिर्फ डाल कि स्रोत नियंत्रण प्रणाली में" टिप्पणी के बारे में अनुभव से एक नोट:

यदि यह स्रोत में नहीं है, यह नहीं हुआ।

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

मैं आमतौर पर यह वहाँ डाल पहले, फिर कटौती 'एन पेस्ट एक ही टिप्पणी जब मैं यह जाँच करें।

+1

यहां असहमत हैं। क्या होता है जब आप इस विधि को दोबारा दूर करते हैं? टिप्पणी को हटाने के लिए भी समझदारी होती है। 24 sep. 082008-09-24 21:40:24

+1

निश्चित रूप से, पुराना कोड और संबंधित टिप्पणियां हटाना ठीक है। यह केवल आपकी टिप्पणियों को बाहरी प्रणाली में डालने का हिस्सा है जो उन्हें आपके लिए खो सकता है, जबकि वे अभी भी वैध हैं, मैं असहमत हूं। :-) 24 sep. 082008-09-24 22:05:38

  0

बैकअप। बैकअप। बैकअप? 14 jul. 102010-07-14 17:12:48

+1

बैकअप बेवकूफ को ठीक नहीं कर सकता है। अनुभवहीनता और अनुचित शाखाओं के मॉडल के बारे में अनुच्छेद देखें। 14 jul. 102010-07-14 19:59:16


1

आप कोड को बनाए रखने के कुछ वर्षों के बाद इस तरह की टिप्पणियां जोड़ देते हैं तो आप इतने सारे बग समाधान होगा टिप्पणियां आप कोड को पढ़ने में सक्षम नहीं होंगे।

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


0

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

अन्यथा, चेकइन में आपके द्वारा दर्ज किए गए संदेश में आपके पास आवश्यक सभी जानकारी होनी चाहिए।

चियर्स,

रोब


1

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

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

काफी ईमानदारी से, मुझे वास्तव में अधिकांश स्थितियों के लिए ऐसा करने में मूल्य नहीं दिखता है। अगर मैं जानना चाहता हूं कि क्या बदल गया है, तो मैं उपversण लॉग और diff को देखूंगा।

बस मेरे दो सेंट।


0

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

मेरे अपने कोड में मैं कभी-कभी बगफिक्स टिप्पणी करता हूं।


0

मैं बहु-व्यक्ति परियोजनाओं पर काम नहीं करता हूं, लेकिन कभी-कभी मैं एक यूनिट परीक्षण में एक निश्चित बग के बारे में टिप्पणियां जोड़ता हूं।

याद रखें, बग, बस अपर्याप्त परीक्षण जैसी कोई चीज़ नहीं है।


0

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

अधिकांश समय मैं कोड के लिए इस तरह विशेष टिप्पणी जोड़ें:

// I KNOW this may look strange to you, but I have to use 
// this special implementation here - if you don't understand that, 
// maybe you are the wrong person for the job. 

कठोर लगता है, लेकिन ज्यादातर लोगों को जो खुद को "डेवलपर्स" फोन कोई अन्य टिप्पणी के पात्र हैं।


1

यदि कोड सही किया गया है, तो टिप्पणी बेकार है और किसी के लिए कभी भी रोचक नहीं है - बस शोर।

यदि बग हल नहीं किया गया है, तो टिप्पणी गलत है। फिर यह समझ में आता है। :) तो अगर आप वास्तव में बग हल नहीं किया है तो बस ऐसी टिप्पणियां छोड़ दें।