बग संख्या टिप्पणी

Question

क्यों आप एक नियंत्रित स्रोत कोड के आधार में

// बग 1024

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

Answer 1

मुझे हमारे कोड बेस में दूसरे दिन इनमें से एक उपयोगी पाया गया।

मैंने कहा, "वह वर्कफ़्लो में देर से प्रारंभिक समारोह क्यों बुला रहा है ??"

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

हालांकि मैं कहूंगा कि आम तौर पर मैं आपसे सहमत हूं और स्वयं को सम्मिलित नहीं करता हूं।

मैं यह पसंद करता हूं कि प्रश्न में डेवलपर ने अधिक अर्थपूर्ण तरीके से बग को ठीक किया, ताकि मुझे पहले स्थान पर कोड के बारे में आश्चर्य न हो।

Answer 2

शुद्ध आलस्य। निश्चित रूप से, इसे लंबे समय तक अधिक समय लगता है, लेकिन संक्षेप में "// बग 1024" में कोई भी प्रयास नहीं होता है। आपके पास जितना अधिक कोड होगा, उतना ही बुरा होगा।

Answer 3

आखिरकार, मुझे लगता है कि यह एक बुरा अभ्यास है। यह शामिल करना बेहतर है कि क्यों बग मौजूद है (प्रकार वाई के गुणों में संपत्ति Z नहीं है)। यदि आप चाहें तो आप "बगआईड 12345 में अधिक" शामिल कर सकते हैं।

यदि आप एकाधिक स्तरों पर एकीकृत कर रहे हैं, तो ट्रैक में एक स्रोत कोड दृश्य सीधे बगआईड से लिंक कर सकता है।

Answer 4

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

हाँ, मुझे पता है कि आप पिछले संस्करणों की तुलना कर सकते हैं, लेकिन यह बट में इतना दर्द है जब आपको मामूली कोड अपडेट के बारे में तुरंत अच्छा महसूस करने की आवश्यकता होती है।

Answer 5

कल्पना कीजिए कि आपके पास एक नई बग है जिसे आप संशोधन 12345 में परिवर्तन के लिए ट्रैक करते हैं। आप लॉग को देखते हैं और यह तुरंत आपको बताता है कि बग 1024 परिवर्तन का कारण था।

आप फिर जा सकते हैं और 1024 को देखने के लिए देख सकते हैं कि नया फिक्स बनाने से पहले, क्यों और कब - 'उन सभी पर शासन करने के लिए'।

यदि बग संख्या प्रतिबद्ध संदेश में नहीं है, तो आपको उस बग की खोज करनी होगी जो एक प्रतिबद्ध है - और यह कई हो सकता है (यदि बग एक से अधिक बार रिपोर्ट की जाती है)।

Answer 6

मैं आपसे सहमत हूं कि इस तरह की टिप्पणी वास्तव में सहायक नहीं है और बहुत संक्षिप्त है।

हालांकि दोष ट्रैकिंग ट्रैकिंग सिस्टम में रिकॉर्ड के संदर्भ के साथ कोड को टिप्पणी करना बेहद उपयोगी और महत्वपूर्ण है (या जो आपके पास किसी भी केएम भंडार में हो सकता है)।

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

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

पीएस आप जोएल ऑन सॉफ्टवेयर सहायक से एमएस ऑफिस के बारे में this लेख पर विचार कर सकते हैं। जहां तक ​​मुझे पता है कि एमएस ऑफिस और एमएस विंडोज़ का कोड समान टिप्पणियों से भरा है जो डेवलपर्स द्वारा किए गए निर्णयों को लंबे समय तक चलाते हैं।

Answer 7

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

Answer 8

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

Answer 9

मुझे लगता है कि यह एक मामला है "मेरे पास एक हथौड़ा है, जो एक नाखून होना चाहिए"। कोड का प्रबंधन करने के लिए आपका टेक्स्ट एडिटर या आईडीई आपका एकमात्र टूल नहीं है।

इतिहास कोड के लिए बाहरी रूप से सर्वोत्तम रूप से बनाए रखा जाता है। कोड का अर्थ टिप्पणियों में वर्णित किया जाना चाहिए जब तत्काल स्पष्ट नहीं है।

मैं मानता हूं कि बग संख्या स्रोत नियंत्रण प्रतिबद्ध संदेशों में होना चाहिए।

Answer 10

मैं ऐसा नहीं करता हूं। मैं एक अच्छे कारण के बारे में नहीं सोच सकता कि आप कोड में दोष आईडी क्यों डाल देंगे। मैं इसे रिलीज नोट्स/चेंजलॉग पर रखूंगा।

क्या मैं उपयोगी मिल रहा है स्वचालित परीक्षण पर नाम के हिस्से के रूप दोष ईद उपयोग कर रहा है:

[TestFixture] 
public class Release_1_2_Bugfixes 
{ 
    [Test] 
    public void TestBug42() 
    { 
    Assert.AreEqual(42, CalculateAnswerToLifeUniverseAndEverything()); 
    } 
} 

मैं other projects देखा है ही बात कर।

Answer 11

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

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

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

Answer 12

आपको कभी भी बग संख्या नहीं जोड़नी चाहिए। यदि आप एक बग के लिए एकाधिक चेकइन बनाते हैं तो आपको बग संख्या और विषय और किसी भी क्वालीफायर को जोड़ना चाहिए:

बग 1111 - 64 बिट सिस्टम पर फू बस्ट।# 2 को ठीक करें क्योंकि ट्रंक में विलय के बाद इसे फिर से खोला गया था।

कुछ सिस्टमों में बग संख्या एकीकरण है। Mxr.mozilla.org में cvs लॉग डिस्प्ले में बग संख्या स्वचालित रूप से bugzilla.mozilla.org संख्या के लिंक में बदल जाती है। जब आप कोड में खुदाई कर रहे हैं, तो यह एक बड़ा टाइमवेवर है। मुझे लगता है कि फोगबगज़ की एक समान सुविधा है ...

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

Answer 13

आपने सिर पर नाखून मारा "प्रासंगिकता बहुत कम रहती है और वे कोड बेस को कूड़ेदान में डालते हैं।"

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

Answer 14

हम कई डेवलपर्स और कई जारी शाखाओं के साथ एक बड़े पैमाने पर सिस्टम पर काम करते हैं।

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

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

Answer 15

मैं इस तरह की भित्तिचित्र को नापसंद करता हूं। अन्य अशिष्ट जीवन के रूपों की तरह वे समय के साथ accrete, कोड आधार चकमा।

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

Answer 16

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

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

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

EDIT: मैं विशेष रूप से उन कोडों के ब्लॉक के साथ डालने का जिक्र कर रहा हूं जो असामान्य हैं या अतिरिक्त संदर्भ की आवश्यकता है।आपके द्वारा बनाए गए प्रत्येक टाइपो फिक्स को टिप्पणी करने में मददगार या आवश्यक नहीं है :-)

Answer 17

इस प्रकार की टिप्पणी आईएस बहुत उपयोगी है: जब आप बग-ट्रैकिंग या स्रोत-नियंत्रण उपकरण बदलते हैं तो क्या होता है? बीजेड 1722 बनाम एफबी 3101 का एक संदर्भ आपको बताएगा कि कौन सा ट्रैकिंग टूल जांचना है (उदाहरण के लिए बगजिला या फोगबगज़)।

Answer 18

यह एक अच्छी बात है!

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

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