निर्देशों का उपयोग 'नामस्थान के अंदर या बाहर होना चाहिए?

Question

मैं कुछ C # कोड पर StyleCop चला रहा हूं , और यह रिपोर्ट करता रहता है कि मेरे usingनिर्देश नाम स्थान के अंदर होने चाहिए।

usingनाम के बाहर के बजाय निर्देशों को अंदर डालने का एक तकनीकी कारण है ?

Comments

कभी-कभी यह फर्क पड़ता है कि आप कहां-कहां डालते हैं: stackoverflow.com/questions/292535/linq-to-sql-designer-bug

— gius

केवल संदर्भ के लिए, प्रति फ़ाइल कई वर्गों के प्रश्न से परे निहितार्थ हैं, इसलिए यदि आप इस प्रश्न के लिए नए हैं, तो कृपया पढ़ते रहें।

— चार्ली

@ उपयोगकर्ता -12506 - यह माध्यम से बड़ी विकास टीम में बहुत अच्छी तरह से काम नहीं करता है जहां कुछ स्तर की कोड स्थिरता की आवश्यकता होती है। और जैसा कि पहले उल्लेख किया गया है, अगर आपको अलग-अलग लेआउट समझ में नहीं आते हैं तो आपको ऐसे किनारे मामले मिल सकते हैं जो आपकी अपेक्षा के अनुरूप काम नहीं करते हैं।

— बेनिफेरस

शब्दावली: वे using कथन नहीं हैं ; वे using निर्देश हैं । usingदूसरी ओर, एक कथन, एक भाषा संरचना है जो एक विधि निकाय आदि के अंदर अन्य कथनों के साथ होती है। उदाहरण के रूप में, using (var e = s.GetEnumerator()) { /* ... */ }एक ऐसा कथन है जो शिथिल रूप से समान है var e = s.GetEnumerator(); try { /* ... */ } finally { if (e != null) { e.Dispose(); } }।

— जेपी स्टिग नील्सन

यदि यह पहले से ही किसी के द्वारा उल्लेख नहीं किया गया था, तो वास्तव में Microsoft भी अपने आंतरिक कोडिंग दिशानिर्देशों मेंusingnamespace

— user1451111

Answer 1

दोनों के बीच वास्तव में एक (सूक्ष्म) अंतर है। कल्पना कीजिए कि आपके पास File1.cs में निम्नलिखित कोड है:

// File1.cs
using System;
namespace Outer.Inner
{
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

अब कल्पना करें कि कोई व्यक्ति इस तरह दिखने वाली परियोजना में एक और फ़ाइल (File2.cs) जोड़ता है:

// File2.cs
namespace Outer
{
    class Math
    {
    }
}

कंपाइलर नेमस्पेस के बाहर Outerउन usingनिर्देशों को देखने से पहले खोजता है , इसलिए यह Outer.Mathइसके बजाय पाता है System.Math। दुर्भाग्य से (या शायद सौभाग्य से?), Outer.Mathकोई PIसदस्य नहीं है , इसलिए File1 अब टूट गया है।

यह परिवर्तन अगर आप usingअपने नाम स्थान घोषणा के अंदर रखते हैं, इस प्रकार है:

// File1b.cs
namespace Outer.Inner
{
    using System;
    class Foo
    {
        static void Bar()
        {
            double d = Math.PI;
        }
    }
}

अब कंपाइलर Systemखोजने से पहले खोजता है Outer, पाता है System.Math, और सब ठीक है।

कुछ का तर्क होगा कि Mathउपयोगकर्ता-परिभाषित वर्ग के लिए एक बुरा नाम हो सकता है, क्योंकि वहां पहले से ही एक है System; यहाँ बात बस इतनी है कि वहाँ है एक अंतर है, और यह अपने कोड के रख-रखाव को प्रभावित करता है।

यह ध्यान रखना दिलचस्प है कि क्या होता है अगर Fooनाम स्थान में है Outer, बजाय Outer.Inner। उस स्थिति में, Outer.Mathफ़ाइल 2 में जोड़ना फ़ाइल 1 को तोड़ता है, जहां usingजाता है। इसका तात्पर्य है कि संकलक किसी भी usingनिर्देश को देखने से पहले नाम स्थान को घेरने वाले अंतरतम को खोजता है ।

Comments

यह मार्क के मल्टीपल-नेमस्पेस-इन-वन-फाइल तर्क की तुलना में स्थानीय रूप से स्टेटमेंट का उपयोग करने के लिए एक बेहतर कारण है। विशेष रूप से संकलन कर सकते हैं और नामकरण क्लैश के बारे में शिकायत करेंगे (इस नियम के लिए StyleCop प्रलेखन देखें (जैसे कि Jared द्वारा पोस्ट किया गया)।

— डेविड श्मिट

स्वीकृत उत्तर अच्छा है, लेकिन मेरे लिए यह एक अच्छा कारण है जैसे कि नाम के बाहर क्लॉस का उपयोग करना । अगर मैं नाम स्थान Outer.Inner में हूँ, तो मैं इसे Outer से गणित वर्ग का उपयोग करने की उम्मीद करूँगा। Inner और System.Math नहीं।

— फ्रैंक वालिस

मैं इसके साथ ही सहमति देता हूं। स्वीकृत उत्तर सही है कि यह तकनीकी रूप से अंतर का वर्णन करता है। हालांकि, एक या दूसरे वर्ग को एक स्पष्ट कॉलआउट की आवश्यकता होगी। मैं अपने स्वयं के स्थानीय वर्ग के लिए "मठ" का बहुत अधिक मूल्यांकन करूंगा, और "System.Math" बाहरी वर्ग का उल्लेख करता हूं - भले ही System.Math का उपयोग Outer.Math के पहले "Math" के रूप में किया जा रहा हो। हाँ, यह पहले से मौजूद कई संदर्भों को ठीक करने के लिए अधिक काम है, लेकिन यह एक संकेत भी हो सकता है कि शायद Outer.Math का एक अलग नाम होना चाहिए!

— mbmcavoy

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

— थाइमिन

मुझे लगता है कि यह आपके उपयोग की जगह बदलने के बजाय एक बुरा नामकरण सम्मेलन है। आपके समाधान में गणित नामक एक वर्ग नहीं होना चाहिए

— jeeveloper

Answer 2

इस थ्रेड में पहले से ही कुछ शानदार उत्तर हैं, लेकिन मुझे लगता है कि मैं इस अतिरिक्त उत्तर के साथ थोड़ा और विस्तार ला सकता हूं।

सबसे पहले, याद रखें कि समय के साथ एक नाम स्थान की घोषणा, जैसे:

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    ...
}

पूरी तरह से इसके बराबर है:

namespace MyCorp
{
    namespace TheProduct
    {
        namespace SomeModule
        {
            namespace Utilities
            {
                ...
            }
        }
    }
}

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

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

अब, आइए स्पष्ट करें कि दो प्रमुख सम्मेलनों के साथ एक ठोस उदाहरण में इसका क्या अर्थ है।

(1) बाहर usings के साथ:

using System;
using System.Collections.Generic;
using System.Linq;
//using MyCorp.TheProduct;  <-- uncommenting this would change nothing
using MyCorp.TheProduct.OtherModule;
using MyCorp.TheProduct.OtherModule.Integration;
using ThirdParty;

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    class C
    {
        Ambiguous a;
    }
}

उपरोक्त मामले में, यह पता लगाने के लिए कि प्रकार क्या Ambiguousहै, इस क्रम में खोज होती है:

1. अंदर के प्रकार C( निहित नेस्टेड प्रकार सहित)
2. वर्तमान नाम स्थान के प्रकार MyCorp.TheProduct.SomeModule.Utilities
3. नाम स्थान में प्रकार MyCorp.TheProduct.SomeModule
4. में टाइप करें MyCorp.TheProduct
5. में टाइप करें MyCorp
6. अशक्त नाम स्थान में प्रकार (वैश्विक नाम स्थान)
7. प्रकार में System, System.Collections.Generic, System.Linq, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, औरThirdParty

अन्य सम्मेलन:

(2) अंदर usings के साथ:

namespace MyCorp.TheProduct.SomeModule.Utilities
{
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using MyCorp.TheProduct;                           // MyCorp can be left out; this using is NOT redundant
    using MyCorp.TheProduct.OtherModule;               // MyCorp.TheProduct can be left out
    using MyCorp.TheProduct.OtherModule.Integration;   // MyCorp.TheProduct can be left out
    using ThirdParty;

    class C
    {
        Ambiguous a;
    }
}

अब, Ambiguousइस क्रम में प्रकार की खोज की जाती है:

1. अंदर के प्रकार C( निहित नेस्टेड प्रकार सहित)
2. वर्तमान नाम स्थान के प्रकार MyCorp.TheProduct.SomeModule.Utilities
3. प्रकार में System, System.Collections.Generic, System.Linq, MyCorp.TheProduct, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, औरThirdParty
4. नाम स्थान में प्रकार MyCorp.TheProduct.SomeModule
5. में टाइप करें MyCorp
6. अशक्त नाम स्थान में प्रकार (वैश्विक नाम स्थान)

(ध्यान दें कि MyCorp.TheProduct"3." का एक हिस्सा था और इसलिए "4." और "5." के बीच की आवश्यकता नहीं थी।)

समापन टिप्पणी

कोई बात नहीं अगर आप नाम स्थान घोषणा के अंदर या बाहर डालते हैं, तो हमेशा संभावना होती है कि कोई व्यक्ति बाद में नाम के समान नाम के साथ एक नया प्रकार जोड़ता है जिसमें उच्च प्राथमिकता होती है।

इसके अलावा, अगर किसी नेस्टेड नेमस्पेस का नाम एक प्रकार के समान है, तो यह समस्याएं पैदा कर सकता है।

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

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

बाहर के उपयोग होने का एक (छोटा) लाभ यह है कि आप [assembly: ComVisible(false)]इसके बजाय वैश्विक विशेषता के लिए निर्देशों का उपयोग कर सकते हैं, उदाहरण के लिए [assembly: System.Runtime.InteropServices.ComVisible(false)]।

Comments

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

— ZunTzu

Answer 3

इसे नामस्थान के अंदर रखने से फ़ाइल के लिए उस नाम स्थान के लिए घोषणाएँ स्थानीय हो जाती हैं (यदि आपके पास फ़ाइल में कई नामस्थान हैं), लेकिन यदि आपके पास प्रति फ़ाइल केवल एक नामस्थान है, तो इससे बहुत फर्क नहीं पड़ता है कि वे बाहर हैं या नहीं नेमस्पेस के अंदर।

using ThisNamespace.IsImported.InAllNamespaces.Here;

namespace Namespace1
{ 
   using ThisNamespace.IsImported.InNamespace1.AndNamespace2;

   namespace Namespace2
   { 
      using ThisNamespace.IsImported.InJustNamespace2;
   }       
}

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

Comments

नेमस्पेस एक तार्किक पृथक्करण प्रदान करते हैं, न कि भौतिक (फाइल)।

— जौइन

यह बिल्कुल सच नहीं है कि कोई अंतर नहीं है; ब्लॉक के usingभीतर निर्देश namespaceसंलग्न namespaceब्लॉक के आधार पर संबंधित नामस्थानों को संदर्भित कर सकते हैं ।

— या मैपर

हाँ मुझे पता हे। हमने पांच साल पहले इस प्रश्न के स्वीकृत उत्तर की स्थापना की।

— मार्क सिडेड 21

Answer 4

हैन्सलमैन के अनुसार - निर्देशन और असेंबली लोडिंग का उपयोग करना ... और ऐसे अन्य लेखों में तकनीकी रूप से कोई अंतर नहीं है।

मेरी प्राथमिकता उन्हें नाम स्थान से बाहर रखना है।

Comments

@ क्रिस एम: उह ... उत्तर में पोस्ट किया गया लिंक इंगित करता है कि इसमें कोई लाभ नहीं है। वास्तव में एक उदाहरण दिखा रहा है जो आपके द्वारा पोस्ट किए गए लिंक में किए गए दावे को गलत साबित करता है ...

— जॉनी

ऐ, मैंने धागा पूरी तरह से नहीं पढ़ा, लेकिन जब एमवीपी ने कहा कि यह सही था, में खरीदा। एक आदमी इसे नापसंद करता है, उसे समझाता है और अपने कोड को और नीचे दिखाता है ... "IL जो C # कंपाइलर जेनरेट करता है, वह या तो मामले में एक जैसा होता है। वास्तव में C # कंपाइलर निर्देशन का उपयोग करते हुए प्रत्येक के अनुरूप कुछ भी नहीं उत्पन्न करता है। निर्देशों का उपयोग करना विशुद्ध रूप से है। सी # वाद, और वे (बयानों प्रयोग करने के लिए सही नहीं है, लेकिन उन कुछ काफी अलग हैं।) नेट ही कोई अर्थ नहीं "। groups.google.com/group/wpf-disciples/msg/781738deb0a15c46

— क्रिस मैककी

कृपया लिंक का सारांश शामिल करें। जब लिंक टूट जाता है (क्योंकि यह होगा , पर्याप्त समय दिया गया है), अचानक 32 अपवोट्स के साथ एक उत्तर केवल लायक है My style is to put them outside the namespaces.- मुश्किल से एक जवाब।

— एवेज़

यहाँ दावा बस गलत है ... एक तकनीकी अंतर है और आपका अपना उद्धरण ऐसा कहता है ... वास्तव में, यही सब कुछ है। कृपया इस गलत उत्तर को हटा दें ... अभी तक बेहतर और सटीक हैं।

— जिम बाल्टर

Answer 5

StyleCop प्रलेखन के अनुसार:

SA1200 :DDirectivesMustBePlacedWithinNamespace

कारण AC # निर्देश का उपयोग करते हुए नाम स्थान तत्व के बाहर रखा गया है।

नियम विवरण इस नियम का उल्लंघन तब होता है जब किसी निर्देश या उपयोग-उर्फ निर्देश को किसी नेमस्पेस तत्व के बाहर रखा जाता है, जब तक कि फ़ाइल में कोई नामस्थान तत्व न हों।

उदाहरण के लिए, निम्न कोड के परिणामस्वरूप इस नियम के दो उल्लंघन होंगे।

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

हालाँकि, निम्न कोड इस नियम के किसी भी उल्लंघन का परिणाम नहीं होगा:

namespace Microsoft.Sample
{
    using System;
    using Guid = System.Guid;

    public class Program
    {
    }
}

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

namespace Microsoft.Sample
{
    using Guid = System.Guid;
    public class Guid
    {
        public Guid(string s)
        {
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            Guid g = new Guid("hello");
        }
    }
}

कोड निम्न कंपाइलर त्रुटि पर विफल रहता है, जिसमें लाइन युक्त पाया जाता है Guid g = new Guid("hello");

CS0576: Namespace 'Microsoft.Sample' में उपनाम 'गाइड' के साथ एक परिभाषा है।

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

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

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

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

2. एकाधिक नामस्थान

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

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

उल्लंघन को कैसे ठीक करें इस नियम का उल्लंघन ठीक करने के लिए, सभी का उपयोग करके निर्देशों का उपयोग करें और नाम स्थान तत्व के भीतर-अन्य निर्देशों का उपयोग करें।

Comments

@Jared - जैसा कि मैंने अपने उत्तर में उल्लेख किया है, मेरा पसंदीदा वर्कअराउंड / सॉल्यूशन केवल एक क्लास प्रति फ़ाइल है। मुझे लगता है कि यह एक काफी सामान्य सम्मेलन है।

— बेयपर्स

वास्तव में, यह एक स्टाइलकॉप नियम भी है! SA1402: AC # दस्तावेज़ में रूट स्तर पर केवल एक ही वर्ग हो सकता है जब तक कि सभी वर्ग आंशिक न हों और एक ही प्रकार के हों। गलत सॉस के साथ एक और ड्रिप को तोड़कर एक नियम दिखाना।

— टास्क

वास्तव में स्टाइलकॉप परिप्रेक्ष्य से इसे कवर करने वाला पहला उत्तर होने के लिए अपवोट किया गया। व्यक्तिगत रूप से मुझे usingनामस्थान के बाहर की दृश्य अनुभूति पसंद है । इनर usingएस मुझे बहुत बदसूरत लगता है। :)

— नवफाल

अंत में सवाल का एक अच्छा जवाब। और बेन्फर्स की टिप्पणी अप्रासंगिक है ... इसका फाइल में कक्षाओं की संख्या से कोई लेना-देना नहीं है।

— जिम बाल्टर

Answer 6

जब आप उपनामों का उपयोग करना चाहते हैं तो नाम स्थान के अंदर बयानों का उपयोग करने के साथ एक समस्या है। उपनाम पहले के usingबयानों से लाभान्वित नहीं होता है और इसे पूरी तरह से योग्य होना चाहिए।

विचार करें:

namespace MyNamespace
{
    using System;
    using MyAlias = System.DateTime;

    class MyClass
    {
    }
}

बनाम:

using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}

यह विशेष रूप से स्पष्ट किया जा सकता है यदि आपके पास लंबे समय से उर्फ ​​जैसे कि निम्नलिखित है (जो कि मुझे समस्या कैसे मिली):

using MyAlias = Tuple<Expression<Func<DateTime, object>>, Expression<Func<TimeSpan, object>>>;

usingनाम स्थान के अंदर बयानों के साथ , यह अचानक हो जाता है:

using MyAlias = System.Tuple<System.Linq.Expressions.Expression<System.Func<System.DateTime, object>>, System.Linq.Expressions.Expression<System.Func<System.TimeSpan, object>>>;

सुंदर नहीं।

Comments

आपके classनाम (पहचानकर्ता) की आवश्यकता है। usingजैसा कि आप संकेत देते हैं कि आपके पास एक वर्ग के अंदर एक निर्देश नहीं हो सकता है। यह एक नेमस्पेस स्तर पर होना चाहिए, उदाहरण के लिए सबसे बाहरी के बाहर namespace, या सिर्फ अंतरतम के अंदर namespace(लेकिन एक वर्ग / इंटरफ़ेस / आदि के अंदर नहीं।)।

— जेपी स्टिग नीलसन 11

@JeppeStigNielsen धन्यवाद। मैंने usingनिर्देशों को गलत तरीके से समझा। मैंने इसे संपादित किया है कि मैंने इसे किस तरह से किया है। इशारा करने के लिए धन्यवाद। तर्क अभी भी वही है, हालांकि।

— नियो

Answer 7

जैसा कि जेपी स्टिग नीलसन ने कहा , इस धागे के पास पहले से ही शानदार जवाब हैं, लेकिन मुझे लगा कि यह स्पष्ट सूक्ष्मता भी ध्यान देने योग्य है।

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

निम्न उदाहरण काम करता है क्योंकि प्रकार Fooऔर Bar, एक ही ग्लोबल नेम स्पेस में दोनों कर रहे हैं Outer।

कोड फ़ाइल Foo.cs मानें :

namespace Outer.Inner
{
    class Foo { }
}

और Bar.cs :

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

usingनिर्देश में बाहरी नामस्थान को छोड़ सकते हैं , संक्षेप में:

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

Comments

यह सच है कि आप "बाहरी नामस्थान को छोड़ सकते हैं," लेकिन इसका मतलब यह नहीं है कि आपको चाहिए। मेरे लिए, यह एक और तर्क है कि निर्देश का उपयोग क्यों किया जाए (उपनाम के अलावा अन्य उपनामों के रूप में @ नियो के उत्तर) को नामस्थान के बाहर जाना चाहिए, ताकि पूरी तरह से योग्य नामस्थान नामों को मजबूर किया जा सके।

— कीथ रॉबर्टसन

Answer 8

एक शिकन में मैं भाग गया (जो अन्य उत्तरों में शामिल नहीं है):

मान लीजिए कि आपके पास ये नामस्थान हैं:

• कुछ अन्य
• Parent.Something.Other

जब आप using Something.Other बाहर का उपयोग करते हैं namespace Parent, तो यह पहले वाले (Some.Other) को संदर्भित करता है।

हालाँकि यदि आप इसे उस नाम स्थान घोषणा के अंदर उपयोग करते हैं , तो यह दूसरे को संदर्भित करता है (Parent.Something.Other)!

एक सरल उपाय है: " global::" उपसर्ग: डॉक्स जोड़ें

namespace Parent
{
   using global::Something.Other;
   // etc
}

Answer 9

उत्तर में तकनीकी कारणों पर चर्चा की जाती है और मुझे लगता है कि यह अंत में व्यक्तिगत प्राथमिकताओं के लिए आता है क्योंकि अंतर इतना बड़ा नहीं है और दोनों के लिए ट्रेडऑफ़ हैं। .csफ़ाइलों का उपयोग करने के लिए विजुअल स्टूडियो का डिफ़ॉल्ट टेम्प्लेटusing जैसे नामस्थान के बाहर निर्देशों का

निम्नलिखित के साथ प्रोजेक्ट फ़ाइल की जड़ में फ़ाइल usingजोड़ने के माध्यम से नामस्थान के बाहर निर्देशों की जांच करने के लिए स्टाइलकॉप समायोजित कर सकते हैं stylecop.json:

{
  "$schema": "https://raw.githubusercontent.com/DotNetAnalyzers/StyleCopAnalyzers/master/StyleCop.Analyzers/StyleCop.Analyzers/Settings/stylecop.schema.json",
    "orderingRules": {
      "usingDirectivesPlacement": "outsideNamespace"
    }
  }
}

आप इस कॉन्फिग फाइल को सॉल्यूशन लेवल में बना सकते हैं और इसे अपने सभी प्रोजेक्ट्स में भी कॉन्फिग शेयर करने के लिए 'मौजूदा लिंक फाइल' के रूप में अपने प्रोजेक्ट्स में जोड़ सकते हैं।

Answer 10

एक और सूक्ष्मता जो मुझे विश्वास नहीं है कि अन्य उत्तरों द्वारा कवर की गई है, जब आप एक ही नाम के साथ एक वर्ग और नाम स्थान रखते हैं।

जब आपके पास नाम स्थान के अंदर आयात होता है तो यह कक्षा को खोज लेगा। यदि आयात नाम स्थान से बाहर है तो आयात को नजरअंदाज कर दिया जाएगा और वर्ग और नाम स्थान को पूरी तरह से योग्य बनाना होगा।

//file1.cs
namespace Foo
{
    class Foo
    {
    }
}

//file2.cs
namespace ConsoleApp3
{
    using Foo;
    class Program
    {
        static void Main(string[] args)
        {
            //This will allow you to use the class
            Foo test = new Foo();
        }
    }
}

//file2.cs
using Foo; //Unused and redundant    
namespace Bar
{
    class Bar
    {
        Bar()
        {
            Foo.Foo test = new Foo.Foo();
            Foo test = new Foo(); //will give you an error that a namespace is being used like a class.
        }
    }
}

Answer 11

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

Comments

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

— हाबिल