क्या यह दिखाने के लिए टिप्पणियां हैं कि कौन सा संस्करण कोड जोड़ा गया था/उपयोगी के लिए संशोधित किया गया था?

Question

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

// added for superEnterpriseyWonder v2.5 
string superMappingTag = MakeTag(extras); 
if (superMappingTag.empty()) 
{ 
    autoMapping = false; 
} 
// end added for superEnterpriseyWonder v2.5 

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

Answer 1

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

क्या बुरा है वे अपने कोड में कुछ और टिप्पणियाँ आकर्षित करेगा यह पूरी तरह से पढ़ने योग्य नहीं

// added for superEnterpriseyWonder v2.5 
string superMappingTag = MakeTag(extras); 
if (superMappingTag.empty()) 
{ 
    // bug fix #12345674 shuld have been true 
    autoMapping = true; 
    // bug fix #12345674 should have been true 
    i++; // v2.6 now need to up the counter DO NOT DELETE 
} 
// end added for superEnterpriseyWonder v2.5 

और फिर किसी विधि हटा देते हैं लेकिन

// added for superEnterpriseyWonder v2.5 
    // bug fix #12345674 should have been true 
    // v2.6 now need to up the counter DO NOT DELETE 
// end added for superEnterpriseyWonder v2.5 

में कोड टिप्पणी छोड़ देंगे बस नहीं कहना बनाने के लिए क्रैपी टिप्पणियों के लिए

Answer 2

विचार करें कि कुछ को वीसीएस से स्नैपशॉट लेना पड़ सकता है। उस स्थिति में, उनके पास वापस गिरने का इतिहास नहीं है .. और ऐसी टिप्पणियां उपयोगी हो जाती हैं।

Answer 3

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

स्वच्छ कोड, बॉब मार्टिन की एक पुस्तक से

यह:

"टिप्पणी के समुचित उपयोग हमारी विफलता कोड में ourself को व्यक्त करने के लिए क्षतिपूर्ति ध्यान दें कि मैं शब्द विफलता इस्तेमाल किया है।। मेरा मतलब था। टिप्पणियाँ हमेशा विफलताओं हैं। "

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

Answer 4

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

मुझे मिला एक और कारण यह था कि कभी-कभी यह जानना महत्वपूर्ण है कि कौन सा संस्करण कोड के साथ जुड़ा हुआ है। बेशक आप हमेशा संस्करण लॉग की जांच कर सकते हैं, लेकिन आपके पास हमेशा इसके लिए समय नहीं है, और यह कष्टप्रद है। कुछ मामलों में "v3.2 के लिए कोड" अन्य डेवलपर्स के लिए "x, y और z करने के लिए कोड" की तुलना में अधिक बोलता है ... यह सब टीम द्वारा स्थापित सम्मेलनों पर निर्भर करता है।

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

Answer 5

मैं कहूंगा कि कोई मूल्य नहीं है: यह जानकारी आपके एससीएम की एनोटेट/दोष कार्यक्षमता के साथ भी पुनर्प्राप्त की जा सकती है। साथ ही, कोई भी इन टिप्पणियों के बीच टेक्स्ट जोड़ सकता है, जो टिप्पणियों की तारीख बनाते हैं (क्योंकि आप v2.6 के लिए कुछ जोड़ सकते हैं जबकि टिप्पणियां v2 कहती हैं।5)

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

Answer 6

कुछ मामलों में उपयोगी हो सकता है (उदाहरण के लिए यदि यह समझने में मदद करता है कि वी 2 में वी 3 में कुछ फ़ंक्शन अलग-अलग क्यों काम करता है) लेकिन सामान्य रूप से, यह एससीएम का काम है कि यह जानने के लिए कि क्या जोड़ा गया है।

Answer 7

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

Answer 8

न केवल यहां कोई मूल्य नहीं है ... नकारात्मक मूल्य है। टिप्पणियों का रखरखाव पहले से ही ज्यादातर जगहों पर स्केची है, यह लोगों के साथ स्क्रू करने के लिए एक और चीज जोड़ता है। इन टिप्पणियों के पास पाठक के लिए कोई मूल्य नहीं है और इसलिए वे अपने दिमाग को बेकार संस्करण जानकारी के साथ छेड़छाड़ कर रहे हैं जब उनके स्मृति में कोड की एक और पंक्ति हो सकती है। यह विलय संघर्ष करने के लिए एक और पंक्ति है (पूरी तरह से मजाक नहीं कर रहा है..मैंने टिप्पणियों पर विलय विवाद देखा है)।

Answer 9

मुझे उन्हें उपयोगी लगता है, यह पता लगाने के लिए वीसीएस के माध्यम से पीछा करता है कि कोड में कोई बदलाव क्यों किया गया था, या दोष के लिए बगआईड खोजने के लिए, मुझे याद आया कि कोड परिवर्तन क्या था।

हालांकि सिद्धांत में वीसीएस में जानकारी है, व्यावहारिक रूप से इसे दफन किया जा सकता है, खासकर एकीकरण द्वारा।

अन्य कार्यों जो आसान है में:

// DEF43562 - changed default value 
foobar = true 

या

1. दोष (या समतुल्य)
2. इतिहास के माध्यम से पीछा सही परिवर्तन खोजने के लिए।
3. स्रोत के लिए का पालन एकीकरण, और दोहराने 1 & 2.
4. ढूँढें बग आईडी मूल परिवर्तन के संलग्न है, अगर आप भाग्यशाली रहे हैं।

असल में टिप्पणी वीसीएस के आसपास एक छोटा सा कट है, और फ्लैकी वीसीएस/बगट्रैकिंग एकीकरण है।

मुझे लगता है कि टिप्पणियां मार्कर के रूप में भी उपयोगी हैं: "इस निर्णय की समीक्षा ग्राहकों/उपयोगकर्ताओं/समीक्षा समिति द्वारा की गई है, और यह चयनित उत्तर है, व्यवहार को बदलने के बारे में सावधान रहें"।

Answer 10

आप picky IMHO नहीं हैं।

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

लाइन हालांकि स्पष्ट नहीं है, क्या

// Compliance with specs abc (additional xyz feature) 
... 
... // some code 

और के बीच का अंतर हो सकता है:

// xyz feature: 
... 
... // some code 

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

मेरी सलाह: एक पद्धति दस्तावेज लिखा है, या एक अनौपचारिक चर्चा है।

Answer 11

यदि सुपरफ्लूओस टिप्पणी देखने से आपके रक्तचाप में वृद्धि होती है, तो आपको पीने या कुछ लेने की आवश्यकता होती है।

उसने कहा, मैं मानता हूं कि ऐसी टिप्पणियां अधिकतर बेकार हैं। यदि लगातार उपयोग किया जाता है, तो कार्यक्रम जल्द ही ऐसी टिप्पणियों का एक भूलभुलैया बन जाएगा। क्या होगा यदि संस्करण 2.5 के लिए एक बार एक पंक्ति बदल दी गई है और फिर एक साल बाद बग 32 9 4 के लिए फिर से बदल दिया गया? क्या आप एक ही पंक्ति पर दो "संस्करण" टिप्पणियां डालते हैं, या बस नवीनतम रखते हैं? यदि आप केवल नवीनतम रखते हैं, तो आप इस तथ्य को खो चुके हैं कि यह मूल रूप से 2.5 के लिए जोड़ा गया था। यदि आप उन्हें दोनों रखते हैं, तो तीसरा परिवर्तन या चौथा होने पर क्या होता है? हम कैसे जानते हैं कि प्रत्येक परिवर्तन पर राज्य क्या था? क्या होता है जब आप संस्करण 2.5 में कोड का एक ब्लॉक जोड़ते हैं, और उसके बाद संस्करण 2.6 के लिए आप 2.5 ब्लॉक के भीतर एम्बेडेड कोड का एक और ब्लॉक जोड़ते हैं? आदि आदि। कार्यक्रम कोड की रेखाओं की तुलना में अधिक संस्करण टिप्पणियां आसानी से समाप्त हो सकता है।

यदि लगातार नहीं किया जाता है, तो टिप्पणियां जल्दी से भ्रामक हो जाएंगी। कोई टिप्पणी कर सकता है कि यह ब्लॉक 2.5 के लिए जोड़ा गया था, कोई और संस्करण 2.6 के लिए उस ब्लॉक के अंदर कोड डाल सकता है और टिप्पणी नहीं कर सकता है, और अब हमारे पास एक टिप्पणी है जो कहती है कि दूसरा ब्लॉक 2.5 के लिए जोड़ा गया था।

और क्या हमें इतना परवाह है? यह बहुत दुर्लभ है कि जब कोई परिवर्तन किया गया तो मुझे परवाह है। ओह, ठीक है कुछ हफ्ते पहले मैंने परवाह की क्योंकि मैं जानना चाहता था कि एक बड़े स्क्रू के लिए दोषी कौन है।

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

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

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