अनावश्यक संदर्भ और उपयोग होने के परिणाम क्या हैं?

12

मैं थोड़ा साफ-सुथरा सनकी हूं और usingप्रत्येक वर्ग में संदर्भों की सफाई करके अपनी परियोजनाएं रखने के लिए हूं और केवल वही रखता हूं जो वास्तव में उपयोग किया जाता है।

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

c# 
— MPelletier
स्रोत
5
ध्यान दें कि usings और संदर्भ समान नहीं हैं। कई जवाबों को ध्यान में रखना विफल रहता है।
— phoog
1
यदि आप कोड को साफ रखना पसंद करते हैं, और न्यूनतम का उपयोग करते हुए, ReSharper खरीदने पर विचार करें। विज़ुअल स्टूडियो का अद्भुत विस्तार। मैं / कार्यक्रम के बिना नहीं रह सकता। ;-)
— एंडर्स
1
— azam

जवाबों:

13

यदि आप usingकम से कम रखते हैं, तो Intellisense आपके लिए बहुत अधिक उपयोगी होगा , और यह एक बड़ा फायदा है।

इसके अलावा, मुझे नहीं लगता कि कोई लाभ है। तो शायद C # संकलक तेजी से काम करेगा, कहते हैं, 1%; तो क्या।

— माइक नाकिस
स्रोत
1
उस 1% का संचयी मूल्य काफी है ... लेकिन मौलिक रूप से आप कंपाइलर से किसी भी समस्या को दूर करने की अपेक्षा करेंगे। हालाँकि, मुझे
— मुश्किल से
C # IntelliSense 2005 के आसपास से वैसे भी थोड़ा गड़बड़ है, जब उन्होंने पूरी तरह से सूची में सब कुछ डंप करना शुरू कर दिया।
— री मियासका
@ReiMiyasaka ताकि आप IntelliSense जो कुछ के लिए आप चाहते हैं और फिर कर पाने के Ctrl+.त्वरित सुधार करने के लिए "नाम स्थान जोड़े XYZ"
— kizzx2
1
@ मर्फ़: चाहे 1% का संचयी मूल्य कितना भी बड़ा क्यों न हो, वह अभी भी संचयी कुल का 1% होगा, इसलिए यह हमेशा असंगत होगा। इसके अलावा, कंपाइलर किसी भी usings की अवहेलना नहीं कर सकता है जब तक कि यह पता नहीं लगा लिया जाता है कि वे वास्तव में अनावश्यक हैं, लेकिन यह पता नहीं लगा सकता है कि जब तक कि उसने आपकी पूरी स्रोत फ़ाइल पहले संकलित नहीं की है। प्रोजेक्ट संदर्भों के अनुसार, उन्हें केवल इसलिए नहीं छोड़ा जाता है क्योंकि वे उपयोग में नहीं आते हैं, क्योंकि उनका उपयोग एक गतिशील (संकलन-समय पर पता लगाने योग्य नहीं) तरीके से किया जा सकता है।
— माइक नाकिस
1
थोड़ा देर से, लेकिन मेरे मामले में हम एक बहुत ही सीमित संसाधन डिवाइस के लिए एक ऐप बना रहे हैं। अनावश्यक संदर्भ जोड़ने से अंतिम आवेदन का आकार प्रभावित होगा। और अच्छी तरह से हम पैकेज को वितरित करने और अन्य पैकेजों के खिलाफ प्रतिस्पर्धा करने की कोशिश करेंगे, एक बड़ा पैकेज उपयोगकर्ता को ऐप डाउनलोड करने या न करने के बारे में दो बार सोच सकता है।
— हम्दीगिरल
9

चूंकि विजुअल स्टूडियो (साधारण राइट क्लिक) में इसे पूरा करना वास्तव में मामूली है, तो ऐसा क्यों न करें?

यह ओकाम के रेजर के अनुरूप है , यह सिर्फ सादा अच्छा इंजीनियरिंग है।

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

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

— JonnyBoats
स्रोत
+1, एक ऐड-इन है जो संपूर्ण समाधान के लिए ऐसा कर सकता है। यह मुझे क्लोजुरस्क्रिप्ट और गूगल क्लोजर वीडियो की भी याद दिलाता है जहां एक वेब पेज के बारे में 1MB है क्योंकि अब पूरा कार्यक्रम अनुकूलन महत्वपूर्ण है। यह एक अच्छी आदत है - जिन चीज़ों की ज़रूरत नहीं है उन्हें साफ़ करने के लिए।
— जॉब
6

usingबयान केवल संकलक के लिए पूरी तरह से संदर्भ कक्षाओं में सक्षम होने के लिए हैं, आदि। अतिरिक्त usingबयानों का संकलन समय पर कोई सराहनीय प्रभाव नहीं होगा।

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

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

— क्वेंटिन-starin
स्रोत
सफाई का उपयोग वीएस 2010 की सुविधा में बनाया गया है (मुझे लगता है कि 2008 भी)। और ReSharper रेफरेंस भी कर सकते हैं। लेकिन, हाँ, इससे पहले कि मैं किसी भी बड़े पैमाने पर सफाई करूं, मैं एक उपकरण का उपयोग करूंगा जो मेरे लिए ऐसा होगा।
— MPelletier
+1 अप्रयुक्त usingऔर अप्रयुक्त संदर्भों के बीच अंतर को स्पष्ट रूप से व्यक्त करने के लिए । दोनों बहुत अलग हैं!
— phoog
1

उपरोक्त के अलावा, मुझे लगता है कि यह अभी तक यहां उल्लेख नहीं किया गया है कि, प्रत्येक संदर्भ को .NET फ्रेमवर्क या बाहरी DLL के भीतर एक घटक की आवश्यकता होती है। यदि संदर्भ किसी बाहरी DLL के लिए बनाया गया है, तो आपको सॉफ़्टवेयर चलाने के लिए (और जहां) होना आवश्यक है।

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

— कोई मौका नहीं
स्रोत
1
यदि संदर्भ अप्रयुक्त है, तो आपको सॉफ़्टवेयर चलाते समय और जहाँ आपको DLL की आवश्यकता नहीं होगी।
— Phoog
@ फोटो, आपकी टिप्पणी के लिए धन्यवाद। कम से कम .NET VS2010 में, यदि आप मैन्युअल रूप से समाधान के लिए एक संदर्भ जोड़ते हैं, तो DLL बिन फ़ोल्डर में भौतिक रूप से जोड़ा जाता है, भले ही आप इसे कोड में उपयोग न करें।
— NoChance
1
लेकिन, यदि आप बिन फ़ोल्डर से DLL को हटाते हैं, या DLL के बिना एप्लिकेशन प्रकाशित करते हैं, तो एप्लिकेशन को अभी भी चलना चाहिए।
— फोज
@ फोटो, आप सही हैं, इसे इंगित करने के लिए धन्यवाद। मैं पोस्ट को संपादित करूंगा।
— NoChance
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.