क्या मुझे अप्राप्त कोड को हटा देना चाहिए?

Question

मैं मध्यम आकार (100k लाइन्स) कोड बेस पर काम कर रहा हूं, यह सभी अपेक्षाकृत हालिया कोड (एक वर्ष से कम पुराना) है और इसमें अच्छी यूनिट टेस्ट कवरेज है।

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

क्या मुझे यह कोड हटा देना चाहिए अगर मुझे यकीन है कि इसकी अब आवश्यकता नहीं है?

इसे हटाने के कारण:

• कम कोड, कम कीड़े
• दूसरों के लिए पचाने में कम कोड आसान है
• यह अभी भी स्रोत नियंत्रण में है

इसे रखने के कारण:

• संदर्भ के रूप में इस्तेमाल किया जा सकता है
• यह कुछ समय के लिए उपयोगी हो सकता है
• यह एक वर्ग के लिए 'राउंड-आउट' कार्यक्षमता के लिए लिखा गया हो सकता है

Comments

"कम कोड, कम कीड़े" - अगर वे वास्तव में कभी उपयोग नहीं किए जाते हैं, तो वे कीड़े पैदा करने की संभावना नहीं हैं

— कोनराड मोरावस्की

@ मोरोस्की लेकिन अगर इसे छोड़ दिया जाता है, तो यह एक दिन इस्तेमाल किया जाएगा। और चूंकि इसे बनाए नहीं रखा गया है, इसमें कीड़े होंगे, जो तब दिखाई देंगे।

— डीजेकेवर्थ

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

— जॉब

@ जोब यदि मुझे कोड आता है तो उसे हटा दिया जाता है। कोई बहना नहीं। बाहर कोड टिप्पणी सिर्फ चिल्लाती है "मुझे हमारे स्रोत नियंत्रण प्रणाली पर भरोसा नहीं है।" मेरे लिए।

— क्रिस्टोफ़ प्रोवोस्ट

@ क्रिस्तोफ प्रोवोस्ट, आपको कैसे पता चलेगा कि उपयोगी कोड एक बार स्रोत फ़ाइल ए में था अगर यह अब वहां नहीं है? बेशक, आप हमेशा उस फ़ाइल के इतिहास की जांच कर सकते हैं जिस पर आप हैं, लेकिन आप अपने आप को कितनी बार सोचते हैं: "हम्म ... मुझे यहां एक फीचर को बदलने / लागू करने की आवश्यकता है। या मुझे यह परीक्षण करने की आवश्यकता है कि यह कैसे काम करता है 5। पहले जल्दी से। मुझे आश्चर्य है कि अगर किसी ने इसे पहले ही लागू कर दिया है और फिर इसे हटा दिया है ... मुझे इतिहास की जांच करने दें "। मैं इस बात की वकालत नहीं कर रहा हूं कि गन्दा बकवास चारों ओर रखा गया है, लेकिन ऐसी परिस्थितियाँ हैं जब आप उत्पादन में कोड का उपयोग नहीं कर रहे हैं, लेकिन डिबगिंग के लिए अवसर पर इसे कर सकते हैं / कर सकते हैं, इत्यादि

— जॉब

Answer 1

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

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

Comments

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

— फाल्कन

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

— 10

@ फाल्कन: यह ओपी का दावा है कि कोड अप्रयुक्त है।

— डेडएमजी

@ स्टॉपरUser: मैं पूरी तरह से सहमत हूं। लेकिन किसी को सावधान रहना चाहिए और अप्रत्याशित तैयारी करनी चाहिए।

— फाल्कन

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

— एंड्रयू टी फिनेल

Answer 2

इसे दूर करने के सभी कारण खड़े हैं।

इसे रखने के कारण:

• संदर्भ के रूप में इस्तेमाल किया जा सकता है
• यह कुछ समय के लिए उपयोगी हो सकता है
• यह एक वर्ग के लिए 'राउंड-आउट' कार्यक्षमता के लिए लिखा गया हो सकता है

इसे रखने के इन सभी कारणों को स्रोत नियंत्रण द्वारा प्रबंधित किया जाएगा। इसे लाइव कोड से हटा दें और यदि आवश्यक हो, तो आप इसे पुनः प्राप्त कर सकेंगे।

Comments

हां, अपरिष्कृत कोड को लाइव कोड में नहीं छोड़ा जाना चाहिए।

— xdazz 16

मुझे लगता है कि आप भी इन लाभों को बस बड़ी मात्रा में टिप्पणी करके प्राप्त करते हैं।

— स्टीव बेनेट

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

— स्टुपरयूजर

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

— स्टीव बेनेट

@ सेवेट बेनेट - यह किसी फ़ाइल के वर्तमान संस्करण में टिप्पणियों की तुलना में "कम दृश्यमान" हो सकता है, लेकिन एकल फ़ाइल के वीसीएस इतिहास की जांच करने के लिए इसका तुच्छ, और मैं txt-file / wiki / etc की तुलना में काफी आसान कहूंगा। .. दृष्टिकोण।

— ज़ैक लिसोबेई

Answer 3

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

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

Comments

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

— स्कॉट व्हिटलॉक

ज्यादा बेहतर सुधार के लिए प्लस 1!

— निकोलस स्मिथ

Answer 4

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

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

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

संक्षेप: मैं सभी अनुपयोगी कोड को तब तक फेंक देता जब तक कि यह एक सामान्य-प्रयोजन मॉड्यूल का हिस्सा नहीं होता जिसे आपने इस तरह से डिज़ाइन किया है और आपको पता है कि आप कई बार पुन: उपयोग करने जा रहे हैं।

नोट : बेशक, एक भी क्लीनर समाधान एक पुस्तकालय के लिए एक अलग परियोजना बनाना होगा, और परियोजनाओं के बीच एक निर्भरता जोड़ना होगा।

Comments

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

— सुपरकट

Answer 5

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

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

Answer 6

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

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

Comments

+1 के लिए "कह रहा है" आप इसे केवल स्रोत नियंत्रण में पा सकते हैं 'अनुमान है कि आप जानते हैं / याद रखें कि यह वहां है! " - कभी-कभी मुझे कोड के छोटे अनुस्मारक मिलते हैं जो किसी कारण या अन्य के लिए सहायक होने के लिए काट दिया गया था।

— स्टीवन

Answer 7

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

दिलचस्प कोड cadavers के लिए, मैं archiveअपने संस्करण नियंत्रण प्रणालियों में एक शाखा का उपयोग करता हूं।

Answer 8

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

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

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

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

Answer 9

अप्रयुक्त विधियों को रखने का एक अच्छा कारण है: उनका उपयोग अन्य शाखाओं / टैगों पर किया जा सकता है!

उन्हें हटाने से पहले अपनी सभी सक्रिय शाखाओं और टैगों का अन्वेषण करें।

Comments

इससे मुझे कोई मतलब नहीं है: यदि इस शाखा में इसका उपयोग नहीं किया जाता है , तो इसे इस शाखा से हटा दें । यदि कोई दूसरी शाखा इसका उपयोग करती है, तो वह वहीं रहेगी।

— साल्स्के

Answer 10

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

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

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

Answer 11

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

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

यदि आप इसे हटाते हैं, लेकिन अपेक्षाकृत जल्दी ही पता चलता है कि आपको वास्तव में इसकी आवश्यकता है, तो यह स्रोत नियंत्रण में वहीं है। यदि आपको इसकी आवश्यकता नहीं है, जब तक कि इतना समय नहीं बीत जाता है कि आपको यह याद नहीं है कि यह स्रोत नियंत्रण में है, तो आप शायद इसे स्क्रैच से वैसे भी लिखना बेहतर समझते हैं।

Answer 12

कुछ भी नहीं कोड की तुलना में कम समय लगता है।

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

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

अगर कुछ नहीं है, तो इसके साथ कोई भी समय नहीं खोएगा।

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

Answer 13

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

पुराने कोड की लंबी टिप्पणियां विचलित करने वाली हैं और कठिन नौवहन करती हैं।

सादर

Answer 14

इस सरल एल्गोरिथ्म का पालन करें:

1. क्या यह एक SCM में समर्थित है? यदि हां, तो 3 पर जाएं।
2. एक SCM सेट करें।
3. सामान दूर फेंक दो ।

हटाने के पक्ष में आपके सभी बिंदु मान्य हैं।

एक बार SCM को देखने या उसे पुनर्स्थापित करने के लिए अव्यवस्था रखने के पक्ष में आपके सभी बिंदु अमान्य हैं। वास्तव में, आपका SCM आपको यह निर्धारित करने में मदद करने में सक्षम होना चाहिए कि यह कोड यहां क्यों है और अप्रयुक्त है, अगर इसका ठीक से उपयोग किया गया था।

इसे एक कारण के लिए "मृत कोड" कहा जाता है। इसे मरने दो और शांति से विश्राम करो।

Answer 15

यह स्रोत नियंत्रण में रहेगा; यह सक्रिय कोड आधार में नहीं रहना चाहिए।

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

Answer 16

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

कोई संदेह नहीं है, अप्रयुक्त कोड एक बुरा गंध है।

अद्यतन करें: मैंने अभी देखा कि एड स्टब ने बहुत ही समान उत्तर दिया।