version control - "टिप्पणी आउट" कोड की जांच




version-control tfs (20)

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

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

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

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

वैसे भी, आपके विचार क्या हैं? क्या आपको विश्वास है कि भंडार में "टिप्पणी की गई" कोड उपयोगी है?

मुझे इस विषय पर दूसरों से सुनने में बहुत दिलचस्पी है।

संपादित करें: स्पष्टता के लिए, हम निजी शाखाओं का उपयोग नहीं करते हैं। अगर हमने ऐसा किया तो मैं कहूंगा कि आप अपनी निजी शाखा के साथ क्या चाहते हैं लेकिन ट्रंक या किसी भी साझा शाखाओं के साथ कोड को कभी भी विलय न करें।

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


अलग-अलग अनुभवों वाले अन्य लोग हो सकते हैं, लेकिन आधा तैयार कोड में जांच में एक भयानक विचार है, अवधि।

यहां सिद्धांत हैं जो मैंने सीखा है और अनुसरण करने का प्रयास करें:

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

इसका मतलब है की:

  • टिप्पणी-आउट कोड को कभी भी चेक नहीं किया जाना चाहिए क्योंकि यह कार्यात्मक नहीं है
  • टिप्पणी एक वैध अभिलेखीय रणनीति नहीं है, इसलिए क्या यह कोड अभी तक समाप्त हो गया है या कोड जो सेवानिवृत्त हो रहा है, टिप्पणी कर रहा है और जांच कर रहा है, कोई समझ नहीं आता है।

तो संक्षेप में, नहीं! यदि कोड अगले चरण में जाने के लिए तैयार नहीं है (जो भी आपके लिए है: IntTest / QA / UAT / PreProd / Prod), यह किसी ट्रंक या बहु-डेवलपर शाखा के लिए प्रतिबद्ध नहीं होना चाहिए। अवधि।

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

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


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

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

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

मेरे लिए टिप्पणी-आउट कोड को आम तौर पर विचारशील सहकर्मी से कम अनादर के संकेत के रूप में देखा जाता है


एक मामला जहां मैंने कोड छोड़ दिया टिप्पणी:

// This approach doesn't work
// Blah, blah, blah

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


कोड में टिप्पणी करने के लिए चेक करने का एक और कारण:

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


दिशानिर्देशों में उपयोग करने के लिए "कभी नहीं" शायद ही कभी एक अच्छा शब्द है।

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

अधिकांश भाग के लिए, मृत कोड को टिप्पणी करना एक अच्छी तरह से प्रबंधित परिवर्तन-नियंत्रित प्रणाली में अनावश्यक है। लेकिन, सभी टिप्पणी कोड "मृत" नहीं है।


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


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

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


मुझे लगता है कि कभी भी एक शर्त बहुत मजबूत नहीं है।

मैं टिप्पणी करता हूं, चेकइन करता हूं, परीक्षण चलाता हूं, सोचता हूं और फिर अगली रिलीज के बाद टिप्पणियां हटा देता हूं।


मुझे लगता है कि टिप्पणी कोड को "अपशिष्ट" माना जाता है।

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

यदि आप सहकर्मी कोड समीक्षा कर रहे हैं तो यह आपके प्रश्न का उत्तर दे सकता है। यदि कोई अन्य डेवलपर आपके कोड की समीक्षा करता है और कहता है, "इस कोड पर टिप्पणी क्यों की गई है जो 'blah' करने का प्रयास कर रहा है" तो आपका कोड कोड समीक्षा में विफल रहा है और आपको इसे किसी भी तरह से जांचना नहीं चाहिए।

टिप्पणी की गई कोड केवल अन्य डेवलपर्स के साथ प्रश्न उठाएगी - इसलिए समय और ऊर्जा बर्बाद कर रही है।

आपको सवाल पूछने की जरूरत है कि " क्यों " कोड पर टिप्पणी की गई है। कुछ सुझाव:

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

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

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

इन सभी संभावित परिदृश्यों (और जिन लोगों का मैंने उल्लेख नहीं किया है) समय और प्रयास बर्बाद कर रहे हैं। टिप्पणी की गई कोड एक छोटी सी समस्या की तरह प्रतीत हो सकती है लेकिन आपकी टीम में एक बड़ी समस्या का संकेतक हो सकता है।


मेरा विचार: यदि डेवलपर अपनी शाखाओं पर या अपने स्वयं के सैंडबॉक्स क्षेत्र में काम कर रहे हैं, तो वे जो कुछ भी चाहते हैं उसे जांचने में सक्षम होना चाहिए। यह तब होता है जब वे एक साझा शाखा (एक फीचर शाखा, या एक टीम की शाखा, या निश्चित रूप से मुख्य / ट्रंक) में कोड की जांच करते हैं कि कोड जितना संभव हो उतना पुराना होना चाहिए (कोड पर कोई टिप्पणी नहीं, कोई और FIXMEs इत्यादि नहीं)।


मैं निश्चित रूप से टिप्पणी-आउट कोड में दृढ़ता से, कभी भी निराश होगा। हालांकि, मैं बिल्कुल इसे प्रतिबंधित नहीं करता। कभी-कभी (यदि शायद ही कभी) स्रोत नियंत्रण में टिप्पणी-आउट कोड की जांच करना उचित है। "ऐसा कभी नहीं करें" कहना बहुत ही सीमित है।

मुझे लगता है कि हम सभी इन बिंदुओं से सहमत हैं:

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

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

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

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

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

रेक्स एम ने कहा: 1) केवल पूर्ण कार्यक्षमता में जांचें, 2) [यदि] कार्य बहुत बड़ा है - इसे छोटे पूर्ण कार्यों में विभाजित करें।

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

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

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

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


मैं पूरी तरह से सहमत हूं कि टिप्पणी कोड को भंडार में चेक नहीं किया जाना चाहिए, यही स्रोत कोड नियंत्रण है।

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

मुझे लगता है कि यह कोड को जटिल बनाता है और इसे पढ़ने में मुश्किल बनाता है।

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


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

मैं उत्तरार्द्ध को "जो लोग अपने संशोधन नियंत्रण प्रणाली का उपयोग गरीब व्यक्ति के टेप बैकअप के रूप में करना चाहते हैं" के रूप में वर्णित करेंगे, लेकिन यह मेरे हाथ को टिप कर देगा कि मैं किस शिविर में हूं। :-)

मेरा अनुमान है कि आप "अच्छे कोड" शिविर में हैं, और वह "कामकाजी कोड" शिविर में से हैं।

[संपादित करें]

टिप्पणियों से, हाँ मैंने सही अनुमान लगाया।

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

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


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

एकमात्र कारण मैं इसे टिप्पणी करूंगा क्योंकि मैं रात भर के निर्माण को तोड़ना नहीं चाहता।


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

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


" Scar Tissue " is what I call commented-out code. In the days before the widespread use of version-control systems, Code Monkeys would leave commented out code in the file in case they needed to revert functionality.

The only time it is acceptable to check-in "scar tissue" is

  1. If you have a private branch and
  2. You don't have time to make the code compile without errors and
  3. You are going on a long vacation and
  4. You don't trust your VCS, like if you use Visual Source Safe OR .
    [EDIT]
  5. You have a subtle bug that might be reintroduced if the incorrect code isn't left in as a reminder. (good point from other answers).

There is almost no excuse for #4 because there are plenty of freely available and robust VCS systems around, Git being the best example .

Otherwise, just let the VCS be your archive and code distributor. If another developer wants to look at your code, email him the diffs and let him apply the stuff he wants directly. In any event, the merge doesn't care why or how the coding of two files diverged.

Because it is code, scar-tissue can be more distracting even than a well-written comment. By its very nature as code, you make the maintenance programmer expend mental cpu-cycles figuring out if the scar-tissue has anything to do with his changes. It doesn't matter whether the scar is a week old or 10 years old, leaving scar-tissue in code imposes a burden upon those who must decypher the code afterwords.

[EDIT] I'd add that there are two major scenarios that need to be distinguished:

  • private development, either coding a personal project or checking in to a private branch
  • Maintenance development, where the code being checked in is intended to be put into production.

Just say "NO" to scar-tissue!


Clearly, the developer who is checking in commented-out code should be working in a separate branch, merging in changes from the trunk branch as neccessary.

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


I don't know - I always comment out the original lines before I make changes - it helps me revert them back if I change my mind. And yes I do check them in.

I do however strip out any old commented code from the previous check-in.

I know I could look at the diff logs to see what's changed but it's a pain - it's nice to see the last changes right there in the code.


I would prefer to see possibly broken, accessible code that isn't being used yet checked in over the same code being completely unavailable. Since all version control software allows some sort of 'working copy' separate from the trunk, it's really a much better idea to use those features instead.

New, non-functional code is fine in the trunk, because it is new. It probably doesn't break anything that already works. If it does break working code, then it should just go in a branch, so that other developers can (if they need to) check that branch out, and see what's broken.


If the developer has commented out some code because it is not yet complete, then the correct "source control" way to deal with this would be for that developer to keep it in a separate branch of his own, until that code is ready to check in.

With a DVCS (like git, bazaar, or mercurial) this is dead easy as it requires no changes in the central repository. Otherwise, perhaps you could talk about giving developers their own branches on the server if they are working on specific features that will take them a long enough time (ie, days).

There is nothing wrong with checking in commented out code in some situations, it's just that this is one situation where there may be a better way to do it, so the developer can track changes to his source even though it isn't ready to be checked in to the main repository.





coding-style