सी # में निर्देशों का उपयोग करके अप्रयुक्त क्यों हटाएं?

Question

मुझे आश्चर्य है कि क्या कोई कारण हैं (स्रोत कोड को छोड़कर) क्यों डेवलपर्स विजुअल स्टूडियो 2008 में "अप्रयुक्त Usings" सुविधा का उपयोग करते हैं?

Answer 1

कुछ कारण हैं जिन्हें आप बाहर ले जाना चाहते हैं।

• यह व्यर्थ है। वे कोई मूल्य नहीं जोड़ते हैं।
• यह भ्रमित है। उस नामस्थान से क्या उपयोग किया जा रहा है?
• यदि आप नहीं करते हैं, तो आप धीरे-धीरे व्यर्थ using कथन जमा करेंगे क्योंकि आपका कोड समय के साथ बदलता है।
• स्थिर विश्लेषण धीमा है।
• कोड संकलन धीमा है।

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

Answer 2

कोड संकलित करता है।

Answer 3

मैं काफी विपरीत कहूंगा - बयान का उपयोग करके अनावश्यक, अनावश्यक को हटाने में बहुत मददगार है।

कल्पना कीजिए कि आपको अपने कोड पर 3, 6, 9 महीने में वापस जाना होगा - या किसी और को अपना कोड लेना होगा और इसे बनाए रखना होगा।

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

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

मार्क

Answer 4

कम Intellisense पॉपअप (विशेषकर यदि नामस्थान एक्सटेंशन तरीकों के बहुत सारे होते हैं) में विकल्प।

सैद्धांतिक रूप से इंटेलिजेंस भी तेज होना चाहिए।

Answer 5

ऐसा लगता है कि यह एक बहुत ही समझदार सवाल है, जिसका जवाब लोगों द्वारा जवाब देने के लिए काफी तेज तरीके से किया जा रहा है।

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

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

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

अगर हम अनावश्यक क्वालिफायर को हटाने को देखो, यह संभवतः भ्रम डेवलपर्स वर्गों के रूप में हमारे डोमेन और डेटा परतों केवल क्वालिफायर द्वारा विभेदित होते हैं करने के लिए हो सकता है।

यदि मैं anachronyms (यानी एबीसीडी -> एबीसीडी) के पूंजीकरण के उचित उपयोग को देखता हूं तो मुझे यह ध्यान रखना होगा कि Resharper किसी भी एक्सएमएल फाइलों को दोबारा प्रतिक्रिया नहीं देता है जिसे हम उस संदर्भ वर्ग नामों का उपयोग करते हैं।

तो, ये संकेत का पालन नहीं कर के रूप में सीधी-सपाट यह प्रतीत होता है, और सम्मान के साथ व्यवहार किया जाना चाहिए के रूप में है।

Answer 6

यह भी झूठी परिपत्र निर्भरता को रोकने में मदद करता है, यह मानते हुए आप भी अप्रयुक्त usings हटाने के बाद अपनी परियोजना से कुछ dll/परियोजना संदर्भ निकाल पा रहे हैं।

Answer 7

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

Answer 8

कारणों को पहले से ही दिए गए के अलावा, यह अनावश्यक नामकरण संघर्ष से बचाता है।

using System.IO; 
using System.Windows.Shapes; 

namespace LicenseTester 
{ 
    public static class Example 
    { 
     private static string temporaryPath = Path.GetTempFileName(); 
    } 
} 

इस कोड संकलन नहीं है क्योंकि दोनों नामस्थान System.IO और System.Windows.Shapes प्रत्येक एक वर्ग पथ कहा जाता है: इस फाइल पर विचार करें। हम पूर्ण वर्ग पथ का उपयोग कर इसे ठीक कर सकता है

 private static string temporaryPath = System.IO.Path.GetTempFileName(); 

या हम बस लाइन using System.Windows.Shapes; को दूर कर सकता है।

Answer 9

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

अब विचार करें, अगर आपको 1000 using निर्देशों के साथ .cs फ़ाइल दी गई थी जो वास्तव में केवल 10 का उपयोग किया गया था। जब भी आप किसी ऐसे प्रतीक को देखते हैं जो बाहरी दुनिया के संदर्भ में कोड में पेश किया गया है, तो आपको यह पता लगाने के लिए उन 1000 लाइनों से गुज़रना होगा। यह स्पष्ट रूप से उपर्युक्त प्रक्रिया को धीमा कर देता है। तो यदि आप उन्हें 10 तक कम कर सकते हैं, तो इससे मदद मिलेगी!

मेरी राय में, सी # using निर्देश बहुत कमजोर है, क्योंकि आप सामान्यता खोए बिना एकल जेनेरिक प्रतीक निर्दिष्ट नहीं कर सकते हैं, और आप विस्तार विधियों का उपयोग करने के लिए using उपनाम निर्देश का उपयोग नहीं कर सकते हैं। जावा, पायथन और हास्केल जैसी अन्य भाषाओं में यह मामला नहीं है, उन भाषाओं में आप बाहरी दुनिया से जो कुछ भी चाहते हैं उसे निर्दिष्ट करने में सक्षम हैं। लेकिन तब घटना, मैं जब भी संभव हो using उपनाम का उपयोग करने का सुझाव दूंगा।

Answer 10

हाल ही में मैं एक और कारण है कि अप्रयुक्त आयात को हटाने काफी उपयोगी और महत्वपूर्ण है मिला है।

कल्पना कीजिए कि आपके पास दो असेंबली हैं, जहां एक दूसरे का संदर्भ देता है (अब के लिए पहले A और संदर्भित B) को कॉल करें। अब जब आपके पास ए में कोड है जो बी पर निर्भर करता है तो सबकुछ ठीक है। हालांकि आपकी विकास प्रक्रिया में कुछ स्तर पर आप ध्यान देते हैं कि आपको वास्तव में उस कोड की आवश्यकता नहीं है, लेकिन आप उस कथन का उपयोग छोड़ दें जहां यह था।अब आप न केवल एक अर्थहीन using -directive लेकिन यह भी एक विधानसभा संदर्भB को जो कहीं भी नहीं किया जाता है, लेकिन अप्रचलित निर्देश में की है। यह A संकलित करने के लिए आवश्यक समय की मात्रा को बढ़ाता है, क्योंकि B को भी लोड किया जाना है।

तो यह न केवल क्लीनर और कोड पढ़ने में आसान है बल्कि उत्पादन-कोड में असेंबली-संदर्भों को बनाए रखने पर भी एक मुद्दा है, जहां उन सभी संदर्भित असेंबली भी मौजूद नहीं हैं।

अंततः हमारे एक्सपैपल में हमें बी और ए को एक साथ भेजना पड़ा, हालांकि बी को ए में कहीं भी नहीं बल्कि using -क्शन में उपयोग किया जाता था। यह बड़े पैमाने पर A जब लोड हो रहा है विधानसभा के क्रम -performance को प्रभावित करेगा।