एक विधि नाम में वर्तनी की गलती को ठीक करना

73

उन तरीकों में से एक जो मैं आमतौर पर हमारे कोडबेस में उपयोग करता हूं, गलत वर्तनी है (और यह मुझे पहले से पता था)।

यह वास्तव में मुझे परेशान नहीं करता है क्योंकि यह गलत है, लेकिन इससे भी महत्वपूर्ण बात यह है कि यह हमेशा नाम गलत हो जाता है पहली बार मैं इसे टाइप करता हूं (और फिर मुझे याद रखना होगा "ओह, ठीक है, इसे गलत तरीके से लिखा जाना चाहिए ...")

मैं मूल विधि के आसपास कुछ बदलाव कर रहा हूं। क्या मुझे केवल फ्रिकिंग विधि का नाम बदलने का अवसर लेना चाहिए?

refactoring

— एक दो तीन
स्रोत

12

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

16

* गलत वर्तनी। और आपको इसे हर जगह बदलना होगा, जिसे विधि कहा जाता है।

— JohnP

2

* गलत वर्तनी ... या शायद एक अलग वर्तनी?

— होरसकॉल

2

@ जॉन्प तीन थे, अब एक तय हो गया है और दो अभी भी गलत हैं। संयोग से ओपी के नाम काफी अच्छी तरह से सूट करते हैं। :)

— मोहभंग

3

हमें कुछ भी गलत नहीं होने देना चाहिए!

— मगस

136

क्या मुझे केवल फ्रिकिंग विधि का नाम बदलने का अवसर लेना चाहिए?

पूर्ण रूप से।

कहा कि, यदि आपका कोड एपीआई के रूप में जारी किया गया है, तो आपको आम तौर पर गलत वर्तनी वाली विधि को छोड़ देना चाहिए और इसे सही तरीके से नामित विधि के लिए आगे रखना चाहिए ( यदि आपकी भाषा ऐसी चीजों का समर्थन करती है तो इसे अप्रचलित चिह्नित करना है )।

— Telastyn
स्रोत

33

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

— dev_feed

2

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

— वू

10

@voo - एह? क्या भाषा एक नई पद्धति को जोड़ देगी (और एक ही सटीक व्यवहार करने के लिए किसी के कार्यान्वयन को बदलकर) पीछे की ओर संगत नहीं होगी?

— तेलस्तीन

3

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

— jwenting

17

@Telastyn यदि गलत तरीके से नाम इंटरफ़ेस पर है (जैसा कि डेल्फी / जावा / सी # में उपयोग किए जाने वाले इंटरफ़ेस प्रकार में है), तो नाम का सही ढंग से वर्तनी वाला संस्करण जोड़ने से संभवतः उक्त इंटरफ़ेस के सभी मौजूदा कार्यान्वयन टूट जाएंगे।

— मोहभंग हुआ

52

ऐसे मामले हैं जहां आपको इस तरह के रिफैक्टरिंग करने से बचना चाहिए:

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

किसी भी अन्य स्थिति में, विधि का नाम बदलने के लिए स्वतंत्र महसूस करें।

— आर्सेनी मूरज़ेंको
स्रोत

1

रिफ्लेक्शन का उल्लेख करने वाली टिप्पणी के लिए +1, यह मुझे एक से अधिक बार काट चुका है।

— द्वादश

33

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

— user2357112

2

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

— user2357112

8

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

— आर्सेनी मूरज़ेंको

5

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

— डेगनलीज

30

मैंने कुछ महीने पहले (अलग-अलग कारणों से) ऐसा किया है। मैंने जो कदम उठाए (भाषा पर्ल थी):

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

बेशक, आपका माइलेज अलग-अलग होगा।

— अबीगैल
स्रोत

एक सुधार - पुराने नाम के उपयोगकर्ताओं को खोजने के लिए grep पर भरोसा न करें, फारवर्डर के अंदर भी लॉग इन करें।

— बेन वोइग्ट

@BenVoigt यह नहीं है कि # 4 क्या करता है?

— बॉब

6

किसी भी मौजूदा कोड को न तोड़ने का एक अच्छा तरीका यह होगा कि नए तरीके के नाम को पुराने तरीके से श्रृंखलाबद्ध किया जाए

private void MyNewMethodName()
{
    TheOldMethodName();
}

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

/ संपादित करें जैसा कि ivo ने टिप्पणी में कहा है: कोड से स्थानांतरित TheOldMethodNameकरने MyNewMethodNameऔर पुरानी पद्धति से नई पद्धति को कॉल करने के लिए एक और भी बेहतर काम होगा । यह भी कोड का है जहाँ चारों ओर सिर पाने के लिए देव की मदद करने के लिए एक फायदा होगा।

— Rémi
स्रोत

2

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

— इवो लिममेन

1

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

— रेमी

1

विधि का नामकरण:

ऐसा न करें कि आप जो चाहते हैं उससे अधिक काम करने के लिए आपके पास ज्यादा से ज्यादा काम हो
यदि आपका आईडीई ऑटो-पूर्ति का समर्थन करता है, तो उस पद्धति को संदर्भित करते समय इसका उपयोग करें

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

— भावुक
स्रोत

0

मैं आमतौर पर हां की सिफारिश करूंगा, इसका नाम बदलूंगा।

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

— ब्रायन
स्रोत