क्या हटाया गया कोड टिप्पणी करने के लिए यह एक अच्छा अभ्यास है? उदाहरण के लिए: एक सहकर्मी की समीक्षा के दौरान मेरे डेवलपर समूह मेंहटाए गए कोड को टिप्पणी कर रहे हैं
// Code to do {task} was removed by Ajahn on 10/10/08 because {reason}.
किसी ने एक नोट है कि हम कोड की लाइनें टिप्पणी चाहिए हटा दिया जाना चाहिए बनाया है। मैंने सोचा कि यह एक भयानक सुझाव था, क्योंकि यह बेकार टिप्पणियों के साथ कोड को अव्यवस्थित करता है। हम में से कौन सा सही है?
आम तौर पर, हटाए गए कोड को टिप्पणी नहीं की जानी चाहिए, ठीक है क्योंकि यह कोडबेस को रोकता है (और, क्यों कोई ऐसी चीज़ पर टिप्पणी करेगा जो मौजूद नहीं है?)।
आपकी दोष ट्रैकिंग प्रणाली या स्रोत नियंत्रण प्रबंधन उपकरण ऐसे स्थान हैं जहां ऐसी टिप्पणियां हैं।
सवाल यह है कि, आप कोड क्यों हटाते हैं?
क्या यह बेकार है? क्या इसे पहली जगह में रखना गलती थी?
मेरे दृष्टिकोण से कोई टिप्पणी की आवश्यकता नहीं है।
मैं मानता हूं कि टिप्पणियों में कोड को छोड़ना अच्छा नहीं है।
कोड इतिहास को संस्करण नियंत्रण प्रणाली के माध्यम से देखा जाना चाहिए, जहां पुराना कोड पाया जा सकता है, साथ ही साथ इसे हटा दिया गया कारण भी है।
डीबगिंग करते समय यह उपयोगी होता है, लेकिन कोड में इस तरह से कोई कारण नहीं है। स्रोत नियंत्रण का पूरा बिंदु टिप्पणी किए गए कोड के साथ कोड को छेड़छाड़ किए बिना पुराने संस्करणों को पुनर्प्राप्त करने में सक्षम है।
आपको हमेशा कोड हटा देना चाहिए।
पुराने/हटाए गए कोड को देखने में सक्षम होने के नाते, यह संशोधन नियंत्रण है।
हाँ, क्योंकि डेवलपर हमेशा इसे बदलने से पहले प्रत्येक फ़ाइल के संस्करण इतिहास को देखते हैं। मानव प्रकृति को ध्यान में रखने के लिए सबसे अधिक 'सही' समाधान को tweaked की जरूरत है। –
अच्छा, अगर आपको पुराने कोड की आवश्यकता है, तो संशोधन नियंत्रण इसे ढूंढने में मदद करेगा। बड़ी मात्रा में कोड पर टिप्पणी करने से सिग्नल को मारने वाले शोर को और अधिक शोर मिल जाता है। – Marko
मैं भी लगता है कि यह एक भयानक सुझाव :)
आप स्रोत नियंत्रण का उपयोग करना चाहिए और आप टिप्पणी जोड़ सकते हैं अगर आप कुछ कोड को दूर जब आप करते हैं। यदि आप चाहते हैं तो आपके पास अभी भी कोड इतिहास है ...
यदि आप कोड निकाल रहे हैं। आपको टिप्पणी नहीं करनी चाहिए कि आपने इसे हटा दिया है। यह स्रोत नियंत्रण का पूरा उद्देश्य है (आप स्रोत नियंत्रण का उपयोग कर रहे हैं? ठीक है?), और जैसा कि आप टिप्पणी देते हैं, बस कोड को अपनाना है।
मैं मानता हूं कि यह एक भयानक सुझाव है। यही कारण है कि आपके पास स्रोत नियंत्रण है जिसमें संशोधन हैं। यदि आपको वापस जाना है और दो संशोधनों के बीच क्या बदला गया है, तो दो संशोधनों को अलग करें।
मैं सुझाव दूंगा कि, हाँ हटा दिया गया कोड पर टिप्पणी करने का अच्छा अभ्यास है लेकिन कोड में नहीं है।
इस स्थिति को और स्पष्ट करने के लिए, आपको एक स्रोत कोड नियंत्रण प्रणाली (एससीसीएस) का उपयोग करना चाहिए जो चेक-इन टिप्पणी के कुछ रूपों की अनुमति देता है। यही वह जगह है जहां आपको टिप्पणियां दी जानी चाहिए कि कोड क्यों हटाया गया था। एससीसीएस कोड के साथ क्या हुआ है, इसका पूरा प्रासंगिक इतिहास प्रदान करेगा, जिसमें हटा दिया गया है। चेक-इन टिप्पणियां जोड़कर आप उस इतिहास को और स्पष्ट करते हैं।
कोड में टिप्पणियां जोड़ना सीधे अव्यवस्था की ओर जाता है।
हालिया आम सहमति (यहां पर अन्य चर्चाओं से) यह है कि कोड को हटाया जाना चाहिए।
मैं व्यक्तिगत रूप से कोड पर टिप्पणी करूंगा और इसे किसी दिनांक या कारण से टैग करूंगा। यदि यह पुराना/पुराना है और मैं फ़ाइल से गुज़र रहा हूं, तो मैंने इसे बाहर कर दिया। संस्करण नियंत्रण वापस आसान बनाता है, लेकिन असम्बद्ध के रूप में आसान नहीं है ...
मैं अप्रयुक्त कोड पर टिप्पणी करता हूं क्योंकि आप कभी नहीं जानते कि आपको प्राचीन कोड पर कब गिरना होगा, और शायद पुराना कोड अन्य लोगों को समझने में मदद करेगा अगर, तो यह वापस आसान था।
मुझे कोड देखने से नफरत है जो कोड से टिप्पणी करने के साथ घिरा हुआ है। कोड हटाएं और एक प्रतिबद्ध संदेश लिखें जो कहता है कि इसे क्यों हटा दिया गया था। आप स्रोत नियंत्रण का उपयोग करते हैं, है ना?
मृत कोड के साथ सक्रिय कोड कूड़े मत करो।
हटाने के कारण पर निर्भर करता है।
मैं टिप्पणियों के बारे में सोचता हूं कि भविष्य में कोड बनाए रखने वाले लोगों के लिए संकेत के रूप में, अगर कोड वहां मौजूद जानकारी थी लेकिन हटा दिया गया था तो कोड को बनाए रखने वाले किसी के लिए सहायक हो सकता है (शायद "ऐसा न करें" चिह्न) तो यह वहां होना चाहिए।
अन्यथा प्रत्येक कोड परिवर्तन पर नामों और तिथियों के साथ विस्तृत टिप्पणियां जोड़ने से पूरी चीज अपठनीय हो जाती है।
मैं सर्वसम्मति से अपनी आवाज़ जोड़ूंगा: कोड नियंत्रण में कोड नियंत्रण संग्रह में कोड क्यों हटा दिया गया था, इस पर टिप्पणियां डालें।
मैं आपके साथ एंड्रयू से सहमत हूं; आईएमओ यही कारण है कि आप संस्करण नियंत्रण का उपयोग करते हैं। अच्छी चेकइन/प्रतिबद्ध टिप्पणियों और एक diff टूल के साथ आप हमेशा यह पता लगा सकते हैं कि लाइनें क्यों हटा दी गईं।
आप स्रोत नियंत्रण के किसी भी रूप का उपयोग कर रहे हैं तो इस दृष्टिकोण (जब तक वर्णनात्मक लॉग संदेशों उपयोग किया जाता है)
मुझे लगता है कि यह बहुत बेकार है और कोड कम पठनीय बनाने के लिए कुछ हद तक निरर्थक है। बस लगता है कि यह कुछ monthes के बाद तरह होगा ....
// removed because of this and that
/*
removed this stuff because my left leg...
*/
doSomething();
// this piece of has been removed, we don't need it...
आप पता लगाने के लिए क्या
ऐसा लगता है कि आप अपने कोड वर्ज़निंग चारों ओर पाने के लिए कोशिश कर रहे हैं हो रहा है आधे घंटे खर्च करेंगे । सिद्धांत रूप में, यह एक महान विचार की तरह लगता है, लेकिन व्यवहार में यह बहुत ही भ्रमित हो सकता है।
मैं अत्यधिक डिबगिंग या अन्य परीक्षण चलाने के लिए कोड को टिप्पणी करने की अत्यधिक अनुशंसा करता हूं, लेकिन अंतिम निर्णय के बाद इसे पूरी तरह से फ़ाइल से हटा दिया गया है!
जगह पर एक अच्छी संस्करण प्रणाली प्राप्त करें और मुझे लगता है कि आप पाएंगे कि परिवर्तनों पर टिप्पणी करने का अभ्यास गन्दा है।
कोड (टिप्पणी हटाने के बजाय) पर टिप्पणी करते समय कुछ (दुर्लभ) स्थितियां एक अच्छा विचार है। यहां एक है।
मेरे पास कोड की एक पंक्ति थी जो अच्छी और आवश्यक लगती थी। बाद में मुझे एहसास हुआ कि यह अनावश्यक और हानिकारक है। रेखा को हटाने के बजाय, मैंने टिप्पणी की, एक और टिप्पणी जोड़ना: "नीचे दी गई रेखा इस तरह के और इस कारण के लिए गलत है"। क्यूं कर?
क्योंकि मुझे यकीन है कि कोड के अगले पाठक को पहले लगता है कि यह लाइन एक त्रुटि है और इसे वापस जोड़ने का प्रयास करेगा। (भले ही पाठक अब से दो साल हो।) मुझे उम्मीद नहीं है कि वह पहले स्रोत नियंत्रण से परामर्श करे। मुझे इस मुश्किल परिस्थिति के बारे में चेतावनी देने के लिए टिप्पणी जोड़ने की जरूरत है; और गलत रेखा होने और कारण यह गलत है कि ऐसा करने का सबसे अच्छा तरीका बन गया।
क्यों मेटा तरीके से बताई गई विधि या कक्षा या फ़ंक्शन इत्यादि में कोई टिप्पणी क्यों न करें, पहले और किस तरह से काम नहीं किया गया था, शायद किसी दिए गए संशोधन के सूचक के साथ, 'कोड' छोड़े बिना स्रोत फ़ाइल? यही वह है जो मैं करने की ओर झुकता हूं। –
क्योंकि यह कोड की केवल रेखा है, इसलिए कोई भी मेटा-वे विवरण लंबा हो जाएगा और कोड को और अधिक अव्यवस्थित करेगा। –
क्यों न केवल टूटी हुई व्यवहार के लिए एक परीक्षण शामिल है जो यूनिट परीक्षणों में हुई रेखा है? – RHSeeger
यहां किसी ने भी के बारे में बहुत कुछ लिखा है क्यों आपको टिप्पणी-आउट कोड छोड़ना नहीं चाहिए, इसके अलावा यह गन्दा दिखता है। मुझे लगता है कि सबसे बड़ा कारण यह है कि कोड काम करना बंद कर सकता है। कोई भी इसे संकलित नहीं कर रहा है। यूनिट परीक्षणों के माध्यम से कोई भी इसे चला रहा है। जब लोग शेष कोड को दोबारा प्रतिक्रिया देते हैं, तो वे इसे दोबारा नहीं कर रहे हैं। बहुत जल्द, यह बेकार बनने जा रहा है। या बेकार से भी बदतर - कोई इसे असम्बद्ध कर सकता है, अंधेरे से भरोसा करता है कि यह काम करता है।
बार हैं जब मैं कोड पर टिप्पणी करूंगा, अगर हम अभी भी एक परियोजना पर भारी डिजाइन/विकास कर रहे हैं। इस स्तर पर, मैं आम तौर पर सही दृष्टिकोण की तलाश में कई अलग-अलग डिज़ाइनों का प्रयास कर रहा हूं। और कभी-कभी सही दृष्टिकोण वह है जिसे मैंने पहले ही प्रयास किया था। तो यह अच्छा है अगर उस कोड को स्रोत नियंत्रण की गहराई में खोया नहीं गया है। लेकिन एक बार डिजाइन का निपटारा हो जाने के बाद, मैं पुराने कोड से छुटकारा पाउंगा।
आम तौर पर मैं बहुत कम टिप्पणी करता हूं। मेरा मानना है कि बिना किसी टिप्पणी के अच्छे कोड को पढ़ना आसान होना चाहिए।
मैं भी अपना कोड संस्करण। मुझे लगता है कि मैं पिछले बीस चेकइन पर अंतर कर सकता हूं यह देखने के लिए कि किसी विशेष कारण के लिए कोई विशेष पंक्ति बदल गई है या नहीं। लेकिन यह ज्यादातर बदलावों के लिए मेरे समय का एक बड़ा अपशिष्ट होगा।
तो मैं अपने कोड को स्मार्ट तरीके से टिप्पणी करने का प्रयास करता हूं। अगर किसी स्पष्ट कारण के लिए कुछ कोड हटाया जा रहा है, तो मैं हटाने को टिप्पणी करने के लिए परेशान नहीं होगा। लेकिन अगर सूक्ष्म कारण के लिए कोड का एक टुकड़ा हटा दिया जा रहा है (उदाहरण के लिए यह एक ऐसा फ़ंक्शन निष्पादित करता है जिसे अब एक अलग थ्रेड द्वारा संभाला जा रहा है) मैं कोड को टिप्पणी या हटा दूंगा और बैनर टिप्पणी जोड़ूंगा:
// this is now handled by the heartbeat thread
// m_data.resort(m_ascending);
या:
// don't re-sort here, as it is now handled by the heartbeat thread
बस पिछले महीने, मैं कोड है कि मैं एक साल पहले बदल गया था एक विशेष समस्या को हल करने का एक टुकड़ा का सामना करना पड़ा है, लेकिन एक टिप्पणी कारणों का स्पष्टीकरण देने में नहीं जोड़ा। यहाँ
cutoff = m_previous_cutofftime;
और कोड के रूप में यह शुरू में एक सही कटऑफ समय का उपयोग करने के लिए जब एक बाधित राज्य शुरू करने तय किया गया था है:: यहाँ मूल कोड है
cutoff = (!ok_during) ? m_previous_cutofftime : 0;
एक और असंबंधित मुद्दा आया था, जो कोड की एक ही पंक्ति को छूने के लिए हुआ, इस मामले में इसे वापस अपने मूल स्थिति में वापस कर दिया। तो नया मुद्दा अब तय किया गया था, लेकिन पुरानी समस्या अचानक फिर से हो गई। डी 'ओह!
तो अब चेक-इन किया कोड इस तरह दिखता है:
// this works for overlong events but not resuming
// cutoff = m_previous_cutofftime;
// this works for resuming but not overlong events
// cutoff = (!ok_during) ? m_previous_cutofftime : 0;
// this works for both
cutoff = (!resuming || !ok_during) ? m_previous_cutofftime : 0;
, YMMV।
यह उन "टूटा" विंडोज विचारों में से एक है जैसे कंपाइलर संकेत/चेतावनियां बिना किसी परेशानी से बनीं। यह आपको एक दिन चोट पहुंचाएगा और यह टीम में ढीलापन को बढ़ावा देगा।
संस्करण नियंत्रण में टिप्पणी में चेक यह ट्रैक कर सकता है कि इस कोड को क्यों हटाया गया था - अगर डेवलपर ने कोई नोट नहीं छोड़ा, तो उन्हें ट्रैक करें और उन्हें थ्रॉटल करें।
अकेले असंतोषजनक आवाज के रूप में, मैं कहूंगा कि विशेष परिस्थितियों में कोड को टिप्पणी करने के लिए एक जगह है। कभी-कभी, आपके पास डेटा मौजूद होगा जो उस पुराने कोड के माध्यम से चल रहा था और सबसे पुरानी बात यह है कि उस पुराने कोड को स्रोत के साथ छोड़ना है। ऐसे मामले में मैं शायद थोड़ा नोट छोड़ दूंगा कि पुराना कोड बस टिप्पणी क्यों किया गया था। बाद में आने वाले किसी भी प्रोग्रामर पुराने संस्करणों की जांच करने की आवश्यकता को मानसिक रूप से पहचानने के बिना, अभी भी मौजूदा डेटा को समझने में सक्षम होंगे।
आमतौर पर, मुझे कोड पूरी तरह से गड़बड़ हो गया है और जब मैं इसे पार करता हूं तो अक्सर इसे हटा देता हूं।
एक सामान्य "साफ कोड" अभ्यास है जो कहता है कि किसी को भी इसे हटाए जाने के बाद कोड को हटाया जाना चाहिए और चूंकि आपका सीवीएस/एसवीएन इसे किसी भी तरह संग्रहित करेगा।
जबकि मैं सिद्धांत से सहमत हूं, मुझे नहीं लगता कि यह सभी विकास स्थितियों के लिए एक स्वीकार्य दृष्टिकोण है। मेरे अनुभव में बहुत कम लोग कोड में सभी परिवर्तनों और प्रत्येक चेक-इन का ट्रैक रखते हैं। नतीजतन, अगर कोड पर कोई टिप्पणी नहीं की गई है, तो वे कभी भी इस बात से अवगत नहीं हो सकते कि यह कभी अस्तित्व में है।
इस तरह के कोड को टिप्पणी करना एक सामान्य चेतावनी देने का एक तरीका हो सकता है जिसे हटाया जा रहा है, लेकिन निश्चित रूप से, इस बात की कोई गारंटी नहीं है कि इच्छुक पार्टियां कभी भी उस चेतावनी को देख सकें (हालांकि यदि वे अक्सर उस के साथ काम करते हैं फ़ाइल, वे इसे देखेंगे)।
मैं व्यक्तिगत रूप से मानता हूं कि सही तरीका उस कोड को किसी अन्य निजी विधि से बाहर करने के लिए है, और फिर प्रासंगिक हितधारकों से संपर्क करें और वास्तव में कार्य से छुटकारा पाने से पहले लंबित हटाने के बारे में सूचित करें।
जहां हम एक रिलीज चक्र के लिए पुराने कोड पर टिप्पणी करते हैं और उसके बाद टिप्पणियां हटाते हैं। (यह हमें त्वरित फिक्स क्षमता देता है अगर कुछ नया कोड समस्याग्रस्त है और पुराने कोड के साथ प्रतिस्थापित करने की आवश्यकता है।)
मज़े के लिए थोड़ा सा उपदेश: मैं कुछ साल पहले एक कंपनी में था, कुछ भी नहीं जानता स्रोत कोड संस्करण नियंत्रण (वे बाद में इस तरह के उपकरण मिल गया ...)।
तो वे एक नियम था, हमारे सी स्रोतों में: "जब आप एक परिवर्तन करते हैं, पूर्वप्रक्रमक मैक्रो के साथ पुराने कोड को निष्क्रिय":
#ifdef OLD /* PL - 11/10/1989 */
void Buggy()
{
// ...
}
#else
void Good()
{
// ...
}
#end
कहने के लिए कोई ज़रूरत नहीं, हमारे सूत्रों का कहना है जल्दी से पढ़ने योग्य नहीं बन गया! यह बनाए रखने के लिए एक दुःस्वप्न था ...
यही कारण है कि मैंने साइस्टी को नेस्टेड #ifdef/#else/#end और इस तरह के बीच कूदने की क्षमता में जोड़ा ... यह अभी भी अधिक नियमित मामलों में उपयोगी हो सकता है।
बाद में, मैंने एक वीडियोज़ प्राप्त करने के बाद, पुराने कोड से छुटकारा पाने के लिए एक विजुअल स्टूडियो मैक्रो लिखा था!
अब, बुटी-ऑक्सा की तरह, कभी-कभी मुझे यह संकेत देने की आवश्यकता महसूस हुई कि मैंने कुछ कोड क्यों हटा दिया। इसी कारण से, या क्योंकि मैं पुराने कोड को हटाता हूं जो मुझे लगता है कि अब इसकी आवश्यकता नहीं है, लेकिन मुझे पूरा यकीन नहीं है (विरासत, विरासत ...)। स्पष्ट रूप से सभी मामलों में नहीं!
मैं इस तरह की टिप्पणी नहीं छोड़ता, वास्तव में, लेकिन मैं आवश्यकता को समझ सकता हूं।
बदतर में, मैं एक संस्करण में टिप्पणी करता हूं, और अगले संस्करण में सबकुछ हटा देता हूं ...
मेरे वर्तमान काम पर, महत्वपूर्ण स्थानीय परिवर्तनों के लिए, हम पुराने कोड को छोड़ देते हैं लेकिन संपत्तियों द्वारा इसे पुनः सक्रिय कर सकते हैं आपातकालीन। उत्पादन में कुछ समय परीक्षण करने के बाद, हम अंततः पुराने कोड को हटा देते हैं।
, VCS टिप्पणियां सबसे अच्छा विकल्प हैं, लेकिन जब परिवर्तन अन्य बदलाव के साथ एक बड़ी फ़ाइल की कुछ लाइनों, थोड़ा हटाने संदर्भित कठिन हो सकता है ...
लगभग सभी मामलों पुराने कोड में है निश्चित रूप से हटाया जाना चाहिए और अपने आरसीएस में ट्रैक किया जाना चाहिए।
हालांकि सभी चीजों की तरह, मुझे लगता है कि 'सभी हटाए गए कोड हमेशा हटा दिए जाएंगे' एक गलत दृष्टिकोण है।
पुराना कोड कारणों के दर्पण के लिए छोड़ा जा सकता है। कोड छोड़ने का मुख्य कारण यह है कि जब आप कोई डेवलपर चाहते हैं जो पुराने कोड को देखने के लिए भविष्य में कोड के उस अनुभाग में काम कर रहा है।
स्रोत ट्रैकिंग पर निर्भरता स्पष्ट रूप से यह नहीं देती है।
तो, मेरा मानना है कि सही जवाब है:
-Delete पुराने कोड जब तक इसे छोड़ने महत्वपूर्ण जानकारी है कि कोड में अगले डेवलपर की आवश्यकता होगी प्रदान करता है। हां, इसे 99% समय हटा दें लेकिन एक कठोर नियम न बनाएं जो परिस्थितियों की गारंटी देता है जब अगले डेवलपर को बहुत आवश्यक दस्तावेज प्रदान करने की आपकी क्षमता को हटा देगा।
यदि आप बड़े बदलावों के बीच में हैं, और मौजूदा कार्यक्षमता को ठीक करने की आवश्यकता है, तो भविष्य के कोड को टिप्पणी करना एक उचित बात है, बशर्ते आप टिप्पणी करें कि यह भविष्य की कार्यक्षमता है, कम से कम हमारे पास वायदा अनुकूल स्रोत नियंत्रण प्रणाली।
हालांकि, ऐसी स्थितियां हो सकती हैं जिनमें आप कहते हैं "मैंने इसे हटा दिया है, इस वजह से यहां जाना चाहिए" विशेष रूप से यदि यह अनजान है। हालांकि, ये स्थितियां बहुत कम और बहुत दूर हैं। –
यह एक उचित बिंदु है। यह चिह्नित करना कि कोड क्या करता है, यह उम्मीद करने से कहीं अधिक सहज है कि डेवलपर फ़ाइल के पूरे परिवर्तन इतिहास को तैयार करेगा। –