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


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

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


1741
2017-09-24 03:49


मूल


कभी-कभी यह अंतर बनाता है जहां आप उपयोग करते हैं: stackoverflow.com/questions/292535/linq-to-sql-designer-bug - gius
संदर्भ के लिए, प्रति फ़ाइल एकाधिक कक्षाओं के प्रश्न से परे प्रभाव हैं, इसलिए यदि आप इस प्रश्न के लिए नए हैं, तो कृपया पढ़ना जारी रखें। - Charlie
@ उपयोगकर्ता -12506 - यह एक माध्यम से बड़ी विकास टीम में बहुत अच्छी तरह से काम नहीं करता है जहां कोड स्थिरता के कुछ स्तर की आवश्यकता होती है। और जैसा कि पहले उल्लेख किया गया है, यदि आप अलग-अलग लेआउट को नहीं समझते हैं तो आपको किनारे के मामले मिल सकते हैं जो आपकी अपेक्षा के अनुसार काम नहीं करते हैं। - benPearce
शब्दावली: वे नहीं हैं using  बयान; वो हैं using  निर्देशों। ए using दूसरी ओर, बयान एक भाषा संरचना है जो एक विधि निकाय आदि के अंदर अन्य बयानों के साथ होती है। उदाहरण के तौर पर, using (var e = s.GetEnumerator()) { /* ... */ } एक बयान है जो कमजोर जैसा ही है var e = s.GetEnumerator(); try { /* ... */ } finally { if (e != null) { e.Dispose(); } }। - Jeppe Stig Nielsen
यदि इसका पहले से किसी के द्वारा उल्लेख नहीं किया गया था, तो वास्तव में माइक्रोसॉफ्ट भी डालने की सिफारिश करता है using अंदर बयान namespace घोषणाओं में, उनके आंतरिक कोडिंग guidlines - user1451111


जवाब:


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

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

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

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

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

यदि आप डालते हैं तो यह बदलता है 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 निर्देश।


1844
2017-09-30 02:33



यह इमो को मार्क के एकाधिक-नामस्थान-इन-वन-फ़ाइल तर्क की तुलना में स्थानीय रूप से बयानों का उपयोग करने का एक बेहतर कारण है। विशेष रूप से संकलन को नामांकित करें और नामकरण संघर्ष के बारे में शिकायत कर सकते हैं (इस नियम के लिए स्टाइलकॉप दस्तावेज़ देखें (उदाहरण के लिए जेरेड द्वारा पोस्ट किया गया))। - David Schmitt
स्वीकृत उत्तर अच्छा है, लेकिन मेरे लिए यह उपयोग खंडों को रखने का एक अच्छा कारण प्रतीत होता है बाहर नामस्थान अगर मैं नेमस्पेस बाहरी में हूं। अंदर मैं उम्मीद करता हूं कि यह बाहरी से गणित वर्ग का उपयोग करे। आंतरिक और सिस्टम नहीं। गणित। - Frank Wallis
मैं इसके साथ भी सहमत हूं। स्वीकृत उत्तर सही है कि यह तकनीकी रूप से अंतर का वर्णन करता है। हालांकि, एक या दूसरे वर्ग को एक स्पष्ट कॉलआउट की आवश्यकता होगी। मैं बहुत अधिक रेट्रर को अपने स्थानीय वर्ग के लिए "गणित" का संकल्प दूंगा, और "सिस्टम.माथ" बाहरी वर्ग को संदर्भित करता है - भले ही सिस्टम.माथ को बाहरी से पहले "गणित" के रूप में उपयोग किया जा रहा था। गणित अस्तित्व में था। हां, हालांकि यह कई पूर्व-मौजूदा संदर्भों को ठीक करने के लिए और अधिक काम है, लेकिन यह एक संकेत भी हो सकता है जो शायद बाहरी हो। गणित का एक अलग नाम होना चाहिए! - mbmcavoy
महान जवाब, लेकिन मुझे ऐसा लगता है कि मैं केवल स्थानीय रूप से बयानों का उपयोग करके गैर-ढांचा बनाना चाहता हूं, और बयान वैश्विक रूप से उपयोग करके ढांचे को रखना चाहता हूं। किसी के पास और स्पष्टीकरण है कि मुझे अपनी वरीयता पूरी तरह क्यों बदलनी चाहिए? यह भी कहां से आया, वीएस -2008 में टेम्पलेट्स ने नेमस्पेस के बाहर उपयोग किया? - Thymine
मुझे लगता है कि यह आपके उपयोग की जगह बदलने के बजाय एक बुरा नामकरण सम्मेलन है। आपके समाधान में गणित नामक कक्षा नहीं होनी चाहिए - jDeveloper


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

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

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

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

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

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

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

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

(1) बाहर के उपयोग के साथ:

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) अंदर उपयोग के साथ:

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)]


346
2018-04-18 21:00



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


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

using ThisNamespace.IsImported.InAllNamespaces.Here;

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

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

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

178
2017-09-24 03:52



नामस्थान एक तार्किक अलगाव प्रदान करते हैं, भौतिक (फ़ाइल) नहीं। - Jowen
यह सच नहीं है कि कोई फर्क नहीं पड़ता; using भीतर निर्देश namespace ब्लॉक संलग्नक के आधार पर रिश्तेदार नामस्थानों का उल्लेख कर सकते हैं namespace ब्लॉक। - O. R. Mapper
हाँ मुझे पता है। हमने पाया कि पांच साल पहले इस प्रश्न के स्वीकृत उत्तर में। - Mark Cidade


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

मेरी वरीयता उन्हें नामस्थानों के बाहर रखना है।


56
2017-09-24 03:53



@ क्रिस एम: ओह ... उत्तर में पोस्ट किया गया लिंक इंगित करता है कि वहां है नहीं बनाम आउट में लाभ, वास्तव में एक उदाहरण दिखा रहा है जो आपके द्वारा पोस्ट किए गए लिंक में किए गए दावे को गलत साबित करता है ... - johnny
अरे, मैंने धागे को पूरी तरह से पढ़ा नहीं, लेकिन जब एमवीपी ने कहा कि यह सही था तो खरीदा गया। एक लड़का इसे अस्वीकार करता है, उसे समझाता है और अपना कोड आगे दिखाता है ... "आईएल जो सी # कंपाइलर उत्पन्न करता है वह किसी भी मामले में समान होता है। असल में सी # कंपाइलर निर्देश का उपयोग करके प्रत्येक के अनुरूप सटीक कुछ भी उत्पन्न नहीं करता है। निर्देशों का उपयोग पूरी तरह से एक है सी # आईएसएम, और उनके पास .NET के लिए कोई अर्थ नहीं है। (कथन का उपयोग करने के लिए सही नहीं है लेकिन वे कुछ अलग हैं।) " groups.google.com/group/wpf-disciples/msg/781738deb0a15c46 - Chris McKee
कृपया लिंक का सारांश शामिल करें। कब लिंक टूटा हुआ है (क्योंकि यह मर्जी ऐसा होता है, पर्याप्त समय दिया जाता है), अचानक 32 अपवॉट्स के साथ एक जवाब केवल लायक है My style is to put them outside the namespaces. - बिल्कुल जवाब नहीं। - ANeves
यहां दावा केवल गलत है ... एक तकनीकी अंतर है और आपका उद्धरण इतना कहता है ... वास्तव में, यह सब कुछ है। कृपया इस गलत जवाब को हटाएं ... बहुत बेहतर, और सटीक, हैं। - Jim Balter


स्टाइलकॉप दस्तावेज़ीकरण के अनुसार:

एसए 1200: डायरेक्ट डायरेक्टिव्सस्टस्टेप्लेसविथिन नेमस्पेस

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

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

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

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"); 

सीएस0576: नेमस्पेस 'माइक्रोसॉफ्ट। नमूना' में उपनाम 'ग्विड' के साथ विरोधाभासी परिभाषा है

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

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

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

नेमस्पेस तत्व के भीतर-उपनाम निर्देशों का उपयोग करना इसे बग के स्रोत के रूप में समाप्त करता है।

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

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

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

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


45
2017-09-14 15:17



@ जेरेड - जैसा कि मैंने अपने जवाब में उल्लेख किया है, मेरा पसंदीदा कामकाज / समाधान केवल प्रति फ़ाइल एक वर्ग है। मुझे लगता है कि यह एक काफी आम सम्मेलन है। - benPearce
दरअसल, यह स्टाइलकॉप नियम भी है! SA1402: ए सी # दस्तावेज़ में रूट स्तर पर केवल एक वर्ग हो सकता है जब तक कि सभी वर्ग आंशिक नहीं होते हैं और एक ही प्रकार के होते हैं। गलत सॉस के साथ एक और बस ड्रिप को तोड़कर एक नियम दिखा रहा है। - Task
वास्तव में स्टाइलकॉप परिप्रेक्ष्य से इसे कवर करने का पहला जवाब होने के लिए उपरोक्त। व्यक्तिगत रूप से मुझे दृश्य महसूस पसंद है usingनामस्थान के बाहर है। भीतरी usingमुझे बहुत बदसूरत लग रहा है। :) - nawfal
अंत में सवाल का एक अच्छा जवाब। और बेनपियर की टिप्पणी अप्रासंगिक है ... फ़ाइल में कक्षाओं की संख्या के साथ इसका कोई लेना-देना नहीं है। - Jim Balter


जब आप उपनाम का उपयोग करना चाहते हैं तो नामस्थान के अंदर बयान का उपयोग करने के साथ एक समस्या है। उपनाम पहले से लाभ नहीं करता है 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>>>;

सुंदर नहीं।


29
2017-10-10 18:47



तुंहारे class एक नाम (पहचानकर्ता) की जरूरत है। आपके पास नहीं हो सकता using जैसा कि आप इंगित करते हैं, कक्षा के अंदर निर्देश। यह नामस्थान स्तर पर होना चाहिए, उदाहरण के लिए बाहरीतम के बाहर namespace, या बस भीतर के अंदर namespace (लेकिन कक्षा / इंटरफ़ेस / आदि के अंदर नहीं)। - Jeppe Stig Nielsen
@JeppeStigNielsen धन्यवाद। मैंने गलत जगह दी using निर्देश गलती से। मैंने इसे संपादित किया है कि मैंने इसका इरादा कैसे किया। इंगित करने के लिए धन्यवाद। हालांकि, तर्क अभी भी वही है। - Neo


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

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;
    }
}

2
2017-09-17 10:32



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


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

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

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

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


0
2018-06-03 12:38





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


-7
2017-10-14 21:30



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