एक फ़ाइल में संशोधन इतिहास

वोट
2

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

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

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

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

12/03/2009 को 15:38
का स्रोत उपयोगकर्ता
अन्य भाषाओं में...                            


8 जवाब

वोट
5

अधिकांश स्रोत नियंत्रण प्रणाली एक "एन्नोटेट" या "दोष" कमांड है। यह क्या कोड प्रत्येक संशोधन के साथ बदल गया पता चलता है।

चूंकि यह जानकारी कार्यक्रम के व्यवहार को बदलने नहीं है, या यह आसान कार्यक्रम को समझने के लिए बनाने के लिए, यह कार्यक्रम में संबंधित नहीं है।

12/03/2009 को 15:45
का स्रोत उपयोगकर्ता

वोट
3

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

मैं इस समस्या को काम पर हर समय देखते हैं। कोड बेस मैं वर्तमान पर काम कर रहा हूँ वापस 1979 तक फैली आप एक जो नीचे कि समय के साथ बनाया है की तरह टिप्पणी के साथ कठिनाई कल्पना कर सकते हैं:

"रेखा से नीचे है, तो अनपेक्षित समस्याएं आ लौट जाएगा, बग xyz ठीक करने के लिए लगता है"

मुझे पता है यह पहली जगह में एक बहुत वर्णनात्मक टिप्पणी लेकिन SVN / सीवीएस / आदि में बात की इस प्रकार की नहीं है। वास्तव में बहुत आसान है। कि कोड में की तरह एक टिप्पणी को संदेह का बीज बोता है। टिप्पणी हटाया जा सकता है? अनपेक्षित मुद्दा यह है कि मुझे इस टिप्पणी से संबंधित कोड पर वापस नज़र डालने के लिए कारण बना हुआ है है? आदि।

12/03/2009 को 15:51
का स्रोत उपयोगकर्ता

वोट
3

कोड में प्रलेखन वर्तमान कोड यह निकट है वर्णन करना चाहिए। कोड बदल देता है, प्रलेखन भी तदनुसार बदलना चाहिए। संस्करण नियंत्रण प्रणाली के प्रबंधन क्या बदल का ध्यान रखना चाहिए और क्यों यह बदल दिया है। कोड है और यह प्रलेखन यह काम (काम करना, और कैसे / क्यों उन चीजों से किया जाता है का वर्णन) है, और संस्करण नियंत्रण प्रणाली जाने करना यह काम (नियंत्रित / दस्तावेजीकरण संस्करणों और परिवर्तन) है करते हैं।

जब भी आप वर्तमान (वर्तमान कोड) में इतिहास को दर्शाता है शुरू करते हैं, आप मुसीबत के लिए पूछ रहे हैं। बस लगता है कि क्या कोड का एक विशेष रूप बदल भारी क्षेत्र अगर यह परिवर्तन का एक नंबर था कैसा लगेगा ?!

12/03/2009 को 15:46
का स्रोत उपयोगकर्ता

वोट
2

मैं बस कैसे जानते हुए भी क्या कार्यक्रम करते थे अब यह समझने में मदद करता है सोच रहा हूँ? आप इसे पठनीयता एड्स का कहना है। कैसे?

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

13/03/2009 को 04:19
का स्रोत उपयोगकर्ता

वोट
1

लगता है कि एक कोड के अंदर परिवर्तन टिप्पणी कभी एक व्याख्यात्मक तरह से संभव है मत करो।

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

12/03/2009 को 15:46
का स्रोत उपयोगकर्ता

वोट
0

इस अपने आप का उत्तर देने का वार करने जा।

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

लेकिन कोड अभी भी प्रलेखित किया जाना चाहिए। इसलिए जब आप में नहीं डाल करना

/* ticket 101: add blink tag to headers, JF - 20010102 */

आप में डालने के लिए चाहते हो सकता है

/* make headers blink */

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

16/03/2009 को 17:49
का स्रोत उपयोगकर्ता

वोट
0

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

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

OTOH - कोड के शरीर में टिप्पणियों के Reams यह क्या यह करता है और जो बदल का वर्णन जब सिर्फ शोर कर रहे हैं।

12/03/2009 को 16:47
का स्रोत उपयोगकर्ता

वोट
0

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

12/03/2009 को 15:45
का स्रोत उपयोगकर्ता

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more