क्या मुझे चर का पुन: उपयोग करना चाहिए?

Question

क्या मुझे चर का पुन: उपयोग करना चाहिए?

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

हालांकि, मैं करना जानते हैं कि सर्वोत्तम प्रथाओं इसके खिलाफ समय के सबसे अधिक कर रहे हैं। उदाहरण के लिए, वे "ओवरराइड" विधि मापदंडों को नहीं कहते हैं।

सर्वोत्तम अभ्यास यहां तक ​​कि पिछले चर को शून्य करने के खिलाफ हैं (जावा में सोनार है जो nullचर को असाइन करते समय एक चेतावनी देता है , कि आपको जावा 6 के बाद से कचरा कलेक्टर को कॉल करने के लिए करने की आवश्यकता नहीं है। आप हमेशा नियंत्रित नहीं कर सकते हैं जो चेतावनियाँ बंद कर दी गई हैं; अधिकांश समय डिफ़ॉल्ट पर है।)

Comments

जावा 6 से? आपको जावा के किसी भी संस्करण में चर को अशक्त करने की आवश्यकता नहीं है। जब एक चर दायरे से बाहर हो जाता है, तो यह अपनी वस्तु का संदर्भ जारी करता है।

— केविन पेंको

चर का फिर से उपयोग करना पहली बात है जो कोड-ऑब्सफ्यूकेटर्स का उपयोग करती है

— लेलोच लैम्परौगे

परिवर्तनीय अपने चर के लिए सभ्य पहचानकर्ता चुनने के साथ फिर से उपयोग करें। आधुनिक भाषाओं में, वास्तव में किसी भी लाभ को फिर से उपयोग करने के लिए परिवर्तनीय नहीं हैं जो अच्छे पहचानकर्ता होने के लाभों से आगे निकल जाते हैं।

— जोरेन

यह भी ध्यान दें कि सभी का पुन: उपयोग नहीं है। पुराने फोरट्रान प्रोग्रामर, यहां तक ​​कि जो अन्य भाषाओं में चले गए हैं, वे नियमित रूप से I, J, K, L, M, N (या i, j, k, l, m, n) का उपयोग हमारे सभी DO-loop (for-) के लिए करते हैं लूप) काउंटर। हम SUM = SUM + A (I, K) * B (K, J), या sum + = a [i] [k] * b [k] [j];

— बजे जॉन आर। स्ट्रॉह्म

बहुत सीमित संसाधनों (कुछ kBytes RAM) के साथ माइक्रोकंट्रोलर की प्रोग्रामिंग करते समय पुन: उपयोग करने योग्य चर को उचित ठहराया जा सकता है।

— m.Alin 19

Answer 1

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

IMO का सबसे अच्छा अभ्यास है, कम पर्याप्त विधियों का उपयोग करना जो केवल एक काम करते हैं, पूरी समस्या को समाप्त करते हैं।

Comments

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

— apter एडेप्टर

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

— पेर्ट टॉर्क

@ डायपर, आपके द्वारा वर्णित परिदृश्य के लिए मैं एक चर का पुन: उपयोग नहीं करूंगा । उपयुक्त बात यह होगी कि result1 = foo(); result2 = foo(); Assert.AreEqual(result1, result2);मैं बहुत से ऐसे स्थान नहीं देख रहा हूँ जहाँ आपको इस मामले में एक चर का पुनः उपयोग करने की आवश्यकता होगी।

— जेएसबी JS

@IAdcape के लिए (int i = 0; i <2; i ++) {result = foo (); assertEquals (अपेक्षित, परिणाम)};}

— बिल K

+1 - यह छोटे तरीकों को बनाने के लिए एक अच्छा कोड गंध है।

Answer 2

एक विधि में चर पुन: उपयोग एक मजबूत संकेत है कि आपको इसे रिफ्लेक्टर / विभाजित करना चाहिए।

तो मेरा उत्तर यह होगा कि आप उन्हें फिर से उपयोग न करें, क्योंकि यदि आप ऐसा करते हैं तो बाद में इसे रिफैक्ट करने के लिए इतना कठिन होगा।

Answer 3

निर्भर करता है।

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

void my_function() {
    HRESULT errorcode;
    errorcode = ::SomeWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
    errorcode = ::AnotherWindowsApiFunction();
    if (FAILED(errorcode)) { /* handle error */ }
}

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

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

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

Answer 4

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

Comments

इसलिए मुझे टेस्ट मेथड लिखना चाहिए जैसे -testSomething और assert for single method invocation -testSomethingTwoInvocations और asserts केवल दूसरे इंवोकेशन के लिए?

— एडॉप्टर

हाँ। यदि यह पहला या दूसरा पुनरावृत्ति है जो विफल हो गया है तो यह आपकी मदद करता है। mspec इसके लिए मदद कर सकता है, इसका वंशानुक्रम वृक्ष बहुत उपयोगी होगा।

— ब्रायन बोएचर

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

— gnasher729

Answer 5

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

संपादित करें: चर का पुन: उपयोग करना कभी-कभी संकेत होता है कि एकल उत्तरदायित्व सिद्धांत का उल्लंघन किया गया है। यह देखने के लिए जांचें कि क्या पुन: उपयोग किया गया चर समान भूमिका में उपयोग किया गया है। यदि यह है, तो यह फिर से उपयोग नहीं किया जा सकता है (हालांकि यह अभी भी दो भिन्न चर रखने के लिए बेहतर हो सकता है, उक्त चर के दायरे को प्रतिबंधित करने के लिए)। यदि इसका उपयोग विभिन्न भूमिकाओं में किया जाता है, तो आपके हाथों पर एसआरपी का उल्लंघन होता है।

Answer 6

एक स्थिति है जिसमें आप अन्य उत्तरों द्वारा दी गई महान सलाह की परवाह किए बिना एक चर का पुन: उपयोग करना चाह सकते हैं: जब आपके कंपाइलर को मदद के लिए हाथ की आवश्यकता होती है।

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

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

Comments

-1 जब तक आप वास्तविक दुनिया की स्थिति की ओर इशारा नहीं कर सकते, जहां यह वास्तव में होता है, और जहां एक चर का पुन: उपयोग एक प्रशंसनीय अंतर बनाता है। यह एक सैद्धांतिक समस्या का एक सैद्धांतिक समाधान है, और उस पर बहुत अच्छा नहीं है। जहां संकलक चर लगाने का फैसला करता है, संकलक की चिंता है; यदि आपका कंपाइलर खराब कोड उत्पन्न करता है, और यदि यह वास्तव में फर्क करता है, तो कंपाइलर को ठीक करें या बदलें।

— कालेब

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

— जॉरिस टिम्मरमन्स

+1 मैंने पिछले प्रोजेक्ट में वास्तव में ऐसा प्रयोग किया था (ANSI C में लिखा गया अत्यधिक अनुकूलित मीडिया कोड)। जहाँ तक मुझे याद है कि अंतर आसानी से विधानसभा और मानक बेंचमार्क में दिखाई दे रहा था। कभी नहीं किया और आशा है कि जावा में इस तरह के पुन: उपयोग करने के लिए कभी नहीं होगा।

— gnat

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

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

— कालेब

Answer 7

मैं कहूंगा न।

इस परिदृश्य के बारे में सोचें: आपका कार्यक्रम दुर्घटनाग्रस्त हो गया और आपको एक कोर डंप का निरीक्षण करके क्या हुआ ... क्या आप अंतर देख सकते हैं? ;-)

Comments

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

— विंस्टन एवर्ट

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

— फोरट्रान

Answer 8

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

Answer 9

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

scrote = int (scrote)

लेकिन मैं अंततः फ़ंक्शन में भेजे गए प्रकार को बदलने और पैरामीटर प्रकार में परिवर्तन को नोट करने के लिए देखूंगा।

Comments

कोड के एक लंबे बैच के बीच में "scrote = int (scrote)" जैसी लाइन डालना रखरखाव प्रोग्रामर को पागल करने का एक शानदार तरीका है।

— झॉकिंग

समस्या "कोड के लंबे बैच" के साथ होने की संभावना है जिसका आप उल्लेख करते हैं।

— धान ३११ Pad

अच्छी तरह से स्वीकार किए गए उत्तर नोटों के रूप में, चर का पुन: उपयोग केवल कोड के लंबे बैचों के साथ वास्तव में एक मुद्दा है। मूल रूप से, किसी भी स्थिति में जहां आप "scrote = int (scrote)" जैसा कुछ लिखेंगे, मैं एक नए चर में int (scrote) डालना पसंद करूंगा, या किसी नए फ़ंक्शन के लिए बेहतर अभी तक int (scrote) पास करूंगा।

— jhocking

Answer 10

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

आपका डिबगर कई चर के साथ एक फ़ंक्शन को डीबग करना भी दर्दनाक बना सकता है। यदि 20 चर के साथ एक फ़ंक्शन 16 चर के साथ एक से अधिक डिबग करना कठिन है, तो आप 5 चर को एक के साथ बदलने पर विचार कर सकते हैं। ("शायद विचार करें" "हमेशा चाहिए" के समान नहीं है)।

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

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

Answer 11

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

आपका डिबगर कई चर के साथ एक फ़ंक्शन को डीबग करना भी दर्दनाक बना सकता है। यदि 20 चर के साथ एक फ़ंक्शन 16 चर के साथ एक से अधिक डिबग करना कठिन है, तो आप 5 चर को एक के साथ बदलने पर विचार कर सकते हैं। ("शायद विचार करें" "हमेशा चाहिए" के समान नहीं है)।

यह ठीक है कि एक चर का कई स्थानों पर उपयोग किया जाता है जब तक कि चर का हमेशा एक ही उद्देश्य हो। उदाहरण के लिए, यदि दस फ़ंक्शन कॉल एक त्रुटि कोड लौटाते हैं, जो प्रत्येक कॉल के लिए तुरंत संभाला जाता है, तो एक चर का उपयोग करें और 10. नहीं। इस के साथ एक समस्या है: आमतौर पर, कंपाइलर आपको बताएगा कि आप किसी अनइंस्टॉल किए गए चर का उपयोग कब करते हैं। लेकिन यहाँ, यदि आप कॉल 6 के बाद त्रुटि कोड पढ़ते हैं, लेकिन चर को वास्तव में कॉल 5 के बाद नहीं बदला गया है, तो आपको संकलक चेतावनी के बिना बेकार डेटा मिलेगा। क्योंकि वैरिएबल को इनिशियलाइज़ किया गया है, डेटा के साथ जो अब बेकार है।

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

Answer 12

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

जब तक आप कोड को हाथ से न देखें या अन्य डेवलपर्स को परेशान न करें।