कोड पर टिप्पणी करना गलत क्यों है और फिर धीरे-धीरे इसे हटाने के लिए कि मैंने पहले से ही क्या किया है और क्या करना बाकी है, का ट्रैक रखना है?

21

जब भी मुझे पता चलता है कि मेरे कोड के एक बड़े हिस्से को बदलने की आवश्यकता है, तो या तो यह गलत है या क्योंकि इसे अन्य कारणों से आवश्यक बड़े वास्तु परिवर्तन के अनुकूल होना है, यही मैं आमतौर पर करता हूं:

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

मुझे ध्यान देना चाहिए कि मैं बड़े पैमाने पर यह व्यक्तिगत परियोजना पर कर रहा हूं जिसे मैं अकेले विकसित कर रहा हूं।

हालाँकि, मुझे बताया गया था, कि मुझे ऐसा करना बंद कर देना चाहिए। मुझे बताया गया था कि इसके बजाय, मुझे पुराने कोड को देखने के लिए पुराने कमिट्स का हवाला देते हुए कमेंट को छोड़ना शुरू करना चाहिए। मुझे बताया गया था:

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

क्या मैं पूछ सकता हूं कि मैं जो कर रहा हूं, उसके ये डाउनसाइड क्या हैं जो मैं अब देखने में असफल हो रहा हूं

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

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

anti-patterns comments

— gaazkam
स्रोत

क्या आप संस्करण नियंत्रण के लिए टिप्पणी कोड को कम कर रहे हैं?

— मोनिका

1

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

— गज़कम

4

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

— मोनिका

4

यह सच है कि यदि आप कोड को cmoment करते हैं, तो आप इसे आसानी से अनइंस्टॉल करके पूर्ववत कर सकते हैं, हालाँकि यदि आपके पास कुछ फाइलों में ssome सामान बदल गया है और वापस जाने की आवश्यकता है, तो आप संस्करण नियंत्रण के बिना काफी खराब हैं। तो "सोर्स कंट्रोल का उपयोग करना शुरू करें" आपकी प्राथमिकता के ऊपर "टिप्पणी कोड नहीं" की तुलना में होना चाहिए :)

— वॉलफ्रैट

2

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

— Doc Brown

29

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

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

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

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

— JimmyJames
स्रोत

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

— पीटर एम

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

— जिमीजैम

मेरे पास कई कोड आधार हैं जिन पर मैं काम करता हूं जो TODO टिप्पणियों से अटे पड़े हैं । यह ईमानदारी से इतना बुरा नहीं है क्योंकि यह आमतौर पर 1-2 लाइनें है। TODO टिप्पणियों के बारे में मुझे जो बात पसंद है, वह यह है कि मेरी IDE में टर्मिनल के पास एक "TODO" टैब है जो टिप्पणी की पूर्वावलोकन और फ़ाइल / लाइन नंबर के साथ टिप्पणियों की सूची के साथ ऑटो-पॉप्युलेट करता है। प्वाइंट, है यह उपयोगी है जब किसी विशेष कंपनी में वे नहीं है दम तोड़ देना उपयोग मुद्दे भले ही वे Git / Github का उपयोग करें। हाँ, अच्छी तरह से आप क्या कर सकते हैं, Google शीट के बजाय Git के मुद्दों का उपयोग करने के लिए प्रबंधन को समझाने की कोशिश करें? हाँ, कोशिश की और विफल रहा। ओह अच्छा। TODO टिप्पणी यह है!

— क्रिस क्रेफ़िस

6

क्या मैं पूछ सकता हूं कि मैं जो कर रहा हूं, उसके ये डाउनसाइड क्या हैं जो मैं अब देखने में असफल हो रहा हूं

यकीनन, कोई नहीं अगर आप अकेले काम करते हैं और संस्करण नियंत्रण का उपयोग नहीं करते हैं और यह महसूस करते हैं कि यह इस तरह से करना ठीक है।

वास्तव में, संस्करण नियंत्रण के बिना यह बहुत मायने नहीं रखता है कि आप "समय" में किसी भी बिंदु पर क्या करते हैं क्योंकि कोड हमेशा ऐसा होता है जो वर्तमान फ़ाइल को ऑपरेटिंग सिस्टम की तरह "सहेजा" जाता है।

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

संभवत: इसकी तुलना हार्ड ड्राइव सॉफ़्टवेयर "स्नैप शॉट्स" से की जा सकती है, जैसे विंडोज में (पुनर्स्थापना की बात) थी। यदि यह इसमें वायरस के साथ एक स्नैपशॉट लेता है, तो आप वायरस को मारते हैं, लेकिन फिर बाद में वापस रोल करने की आवश्यकता होती है, आप एक बिंदु पर वापस जा सकते हैं जहां वायरस फिर से मौजूद है।

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

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

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

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

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

— जेम्स
स्रोत

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

— जूल्स

4

ऐसा लगता है कि आपका समीक्षक थोड़ा हठधर्मी है। मुझे यकीन नहीं है कि बाहर कोड टिप्पणी करने के लिए किसी को शपथ; पीसी;; या यहां तक कि सहायक ;-)

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

और ऐसा करने से कोड को कमेंट करने की आपकी कुछ ज़रूरतें कम हो सकती हैं।

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

/*
 * Need this sort of functionality added back before too long:
 * .... OLD CODE HERE
 */

व्यक्तिगत रूप से, मैं इस तरह से कुछ की ओर अधिक झुकता हूं:

 * TODO:
 *      @todo   Possible get rid of intermediate LRUCache_ object.
 *
 *      @todo   Find some reasonable/simple way to get
 *              LRUCache<PHRShortcutSpec, PHRShortcutSpec, PHRShortcutSpecNoAuthCacheTraits_>   sRecentlyUsedCache (kMaxEltsInReceltlyUsedCache_);
 *              Working with ONE T argument
 *              Add(elt2cache).
 ...

और मैं सहायक के रूप में पुराने कोड से 'कोड स्निपेट' में फेंकने के लिए स्वतंत्र महसूस करता हूं।

गिट का उपयोग करना कठिन (दुख की बात है)। यह सीखने में आपको थोड़ा समय लगेगा, और यह महसूस कर सकता है कि आप इसे पूरा नहीं कर रहे हैं। लेकिन अगर आप उपयोगी तरीके से कार्यक्रम करने जा रहे हैं, तो आपको एक टीम के हिस्से के रूप में ऐसा करना सीखना होगा, और एक टीम के साथ संवाद करना होगा, और यह सिर्फ आजकल कैसे किया जाता है। और एक बार जब आप इसका उपयोग करने के लिए तैयार हो जाते हैं, तो आपको इसका बहुत उपयोगी उपकरण / बैसाखी मिल जाएगी, जिससे आपका सॉफ़्टवेयर विकास आसान हो जाएगा।

शुभकामनाएँ!

— लुईस प्रिंगल
स्रोत

2

कोड टिप्पणी करने के कई कारण हैं: -

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

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

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

— साइमन बी
स्रोत

1

ये बिल्कुल कारण हैं कि आपको एससीएम का उपयोग क्यों करना चाहिए (और इसके भीतर क्रेच)

— टिमोथी

2

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

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

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

— क्रिस कूपर
स्रोत

1

यह बुरा है और आपको रुकना चाहिए ।

कारण एक ही बार में बड़ी मात्रा में रिफैक्टरिंग करने का प्रयास करता है।

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

यदि आप अक्सर जांच नहीं करते हैं, तो आप मर्ज संघर्षों को जमा कर रहे हैं और चरण प्रगति से रिकॉर्डिंग नहीं कर रहे हैं।

आपको अपने काम करने के तरीके को बदलने की ज़रूरत है ताकि अगर आपको बीच का रास्ता रोकना पड़े तो भी सब कुछ काम कर सके।

बच्चे के कदम उठाएं और प्रत्येक के बाद जांच करें:

एक इंटरफ़ेस निकालें
एक परीक्षण लिखें
एक समारोह refactor

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

यदि आपको क्या करने की आवश्यकता है, इस पर नज़र रखने की आवश्यकता है, तो स्क्रैम या ट्रेलो जैसे कार्य बोर्ड का उपयोग करें

— ईवान
स्रोत