'Kullanma' yönergeleri ad alanının içinde mi yoksa dışında mı olmalı?

StyleCop bazı C # kodu üzerinde çalışıyorum ve usingyönergelerimi ad alanı içinde olması gerektiğini bildiriyor .

usingYönergeleri ad alanının dışına koymak yerine teknik bir neden var mı ?

Aslında ikisi arasında (ince) bir fark vardır. File1.cs içinde aşağıdaki kodu olduğunu düşünün:

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

Şimdi birisinin projeye şöyle görünen başka bir dosya (Dosya2.cs) eklediğini düşünün:

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

Derleyici , ad alanının dışındaki yönergelere Outerbakmadan önce arama yapar using, Outer.Mathbunun yerine bulur System.Math. Ne yazık ki (ya da neyse ki?), Üyesi Outer.Mathyok PI, bu yüzden Dosya1 artık bozuk.

Bu using, ad alanı beyanınızın içine aşağıdaki gibi koyarsanız değişir :

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

Derleyici arama Systemyapmadan önce arar Outer, bulur System.Mathve her şey yolunda.

Bazıları bunun Mathkullanıcı tanımlı bir sınıf için kötü bir isim olabileceğini savunur , çünkü zaten bir tane vardır System; nokta burada orada sadece budur olduğunu fark ve bu senin kod yaşatılabilirlik etkiler.

Ayrıca Foo, ad alanında Outerdeğil, ne olduğunu not etmek de ilginçtir Outer.Inner. Bu durumda, Outer.MathDosya2'yi eklemek nereye usinggiderse gitsin Dosya1'i keser . Bu, derleyicinin herhangi bir usingyönergeye bakmadan önce en içteki ad alanında arama yaptığı anlamına gelir .

Bu konu zaten bazı harika cevaplara sahip, ancak bu ek cevapla biraz daha ayrıntı getirebileceğimi hissediyorum.

İlk olarak, noktalarla birlikte bir ad alanı bildirimi unutmayın:

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

tamamen şuna eşittir:

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

İsterseniz using, tüm bu seviyelere direktifler koyabilirsiniz . (Tabii ki, usingsadece bir yerde olmak istiyoruz , ancak dile göre yasal olacaktır.)

: Hangi tip ima çözülmesi için kural, gevşek böyle ifade edilebilir hiçbir şey bu kadar bir sonraki kapsama bir düzey dışarı çıkmak ve orada arama orada bulunan ve eğer Birincisi, maç için iç-en "kapsam" arama , bir eşleşme bulunana kadar. Bir düzeyde birden fazla eşleşme bulunursa, türlerden biri geçerli derlemeden geliyorsa, bunu seçin ve derleyici uyarısı verin. Aksi takdirde vazgeçiniz (derleme zamanı hatası).

Şimdi, bunun iki büyük sözleşmeyle somut bir örnekte ne anlama geldiğini açıklayalım.

(1) dışında kullanımları ile:

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

Yukarıdaki durumda, ne tür Ambiguousolduğunu bulmak için arama şu sırayla yapılır:

1. İçerideki Cyuvalanmış türler (miras alınan yuvalanmış türler dahil)
2. Geçerli ad alanındaki türler MyCorp.TheProduct.SomeModule.Utilities
3. Ad alanındaki türler MyCorp.TheProduct.SomeModule
4. Türleri MyCorp.TheProduct
5. Türleri MyCorp
6. Boş ad alanındaki türler (genel ad alanı)
7. Türleri içinde System, System.Collections.Generic, System.Linq, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, veThirdParty

Diğer sözleşme:

(2) İçindeki kullanımlarla:

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

Şimdi, türü arayın Ambiguousşu sırayla gider:

1. İçerideki Cyuvalanmış türler (miras alınan yuvalanmış türler dahil)
2. Geçerli ad alanındaki türler MyCorp.TheProduct.SomeModule.Utilities
3. Türleri içinde System, System.Collections.Generic, System.Linq, MyCorp.TheProduct, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, veThirdParty
4. Ad alanındaki türler MyCorp.TheProduct.SomeModule
5. Türleri MyCorp
6. Boş ad alanındaki türler (genel ad alanı)

(Bunun MyCorp.TheProduct"3" ün bir parçası olduğunu ve bu nedenle "4." ile "5." arasında gerekli olmadığını unutmayın.)

son sözler

Kullanıcıları ad alanı bildiriminin içine veya dışına koyarsanız da, daha sonra birisinin daha yüksek önceliğe sahip ad alanlarından birine aynı ada sahip yeni bir tür ekleme olasılığı vardır.

Ayrıca, iç içe geçmiş bir ad alanı bir türle aynı ada sahipse, sorunlara neden olabilir.

Arama hiyerarşisi değiştiğinden ve başka bir tür bulunduğundan, kullanımları bir konumdan diğerine taşımak her zaman tehlikelidir. Bu nedenle, bir kongre seçin ve ona sadık kalın, böylece asla kullanıcıları hareket ettirmek zorunda kalmazsınız.

Visual Studio'nun şablonları, varsayılan olarak, kullanımları ad alanının dışına koyar (örneğin , VS'nin yeni bir dosyada yeni bir sınıf oluşturmasını sağlarsanız).

Usings sahip biri (küçük) avantajı dışında daha sonra örneğin bir küresel bir özellik için kullandığınız direktifleri kullanabilmesidir [assembly: ComVisible(false)]yerine [assembly: System.Runtime.InteropServices.ComVisible(false)].

Ad alanlarının içine yerleştirmek, bildirimleri dosya için o ad alanı için yerel hale getirir (dosyada birden fazla ad alanınız olması durumunda), ancak dosya başına yalnızca bir ad alanınız varsa, dışarı çıkıp çıkmadıkları veya ad alanının içinde.

using ThisNamespace.IsImported.InAllNamespaces.Here;

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

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

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

Göre Hanselman - Yönergesi ve Montaj Yükleniyor ... kullanma ve diğer bu tür yazılar teknik bir fark yoktur.

Benim tercihim onları isim alanlarının dışına koymak.

StyleCop Belgelerine Göre:

SA1200: UseDirectivesMustBePlacedWithinNamespace

Neden AC # yönergesini kullanarak bir ad alanı öğesinin dışına yerleştirilir.

Kural Açıklama Dosyada herhangi bir ad alanı öğesi bulunmadığı sürece, kullanım talimatı veya kullanım takma adı yönergesi bir ad alanı öğesinin dışına yerleştirildiğinde bu kuralın ihlali oluşur.

Örneğin, aşağıdaki kod bu kuralın iki ihlaline neden olur.

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

Ancak aşağıdaki kod, bu kuralın herhangi bir ihlaline neden olmaz:

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

    public class Program
    {
    }
}

Bu kod, derleyici hataları olmadan temiz bir şekilde derlenecektir. Ancak, Guid türünün hangi sürümünün tahsis edildiği belirsizdir. Using yönergesi, aşağıda gösterildiği gibi ad alanının içine taşınırsa, bir derleyici hatası oluşur:

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

Kod, aşağıdaki satırda, derleme satırında bulunan başarısız Guid g = new Guid("hello");

CS0576: 'Microsoft.Sample' ad alanı, 'Guid' takma adıyla çakışan bir tanım içeriyor

Kod, Guid adlı System.Guid türüne bir diğer ad oluşturur ve aynı zamanda eşleşen bir yapıcı arabirimiyle Guid adlı kendi türünü oluşturur. Daha sonra kod, Guid türünün bir örneğini oluşturur. Bu örneği oluşturmak için, derleyicinin iki farklı Guid tanımı arasında seçim yapması gerekir. Using-alias yönergesi, ad alanı öğesinin dışına yerleştirildiğinde, derleyici, yerel ad alanında tanımlanan yerel Guid tanımını seçer ve ad alanının dışında tanımlanan use-alias yönergesini tamamen yoksayar. Ne yazık ki, bu kodu okurken belli değil.

Bununla birlikte, use-alias yönergesi ad alanı içinde konumlandırıldığında, derleyici aynı ad alanında tanımlanan iki farklı, çakışan Guid türü arasında seçim yapmak zorundadır. Bu türlerin her ikisi de eşleşen bir kurucu sağlar. Derleyici karar veremediğinden derleyici hatasını işaretler.

Using-alias yönergesini ad alanının dışına yerleştirmek kötü bir uygulamadır, çünkü bu tür durumlarda karışıklığa yol açabilir, burada türün hangi sürümünün gerçekten kullanıldığı açık değildir. Bu, teşhis edilmesi zor olabilecek bir hataya neden olabilir.

Use-alias yönergelerini ad alanı öğesi içine yerleştirmek hata kaynağı olarak bunu ortadan kaldırır.

2. Birden Çok Ad Alanı

Birden çok ad alanı öğesini tek bir dosyaya yerleştirmek genellikle kötü bir fikirdir, ancak bu yapılırsa ve yapıldığında, tüm yönergelerin, genel olarak dosyanın üst kısmına değil, ad alanı öğelerinin her birine yerleştirilmesi iyi bir fikirdir. Bu, ad alanlarını sıkıca kaplayacak ve yukarıda açıklanan davranış türlerinden kaçınmaya yardımcı olacaktır.

Kod, ad alanının dışına yerleştirilmiş yönergeler kullanılarak yazıldığında, kodun anlambilimini değiştirmediğinden emin olmak için, bu yönergeleri ad alanı içinde taşırken dikkatli olunmalıdır. Yukarıda açıklandığı gibi, isim-alanı yönergelerinin ad-alanı elemanına yerleştirilmesi, derleyicinin, direktifler ad alanının dışına yerleştirildiğinde gerçekleşmeyecek şekilde çakışan türler arasında seçim yapmasına izin verir.

İhlallerin Düzeltilmesi Bu kuralın ihlalini gidermek için, ad alanı öğesindeki tüm yönergeleri ve takma ad kullanma yönergelerini taşıyın.

Takma adlar kullanmak istediğinizde, ad alanının içine ifadeler kullanmakla ilgili bir sorun vardır. Takma ad, önceki usingifadelerden yararlanmaz ve tam olarak nitelenmesi gerekir.

Düşünmek:

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

    class MyClass
    {
    }
}

karşı:

using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}

Aşağıdaki gibi uzun soluklu bir takma adınız varsa bu özellikle telaffuz edilebilir (sorunu bu şekilde buldum):

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

İle usingad alanı içine ifadeleri, aniden dönüşür:

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

Güzel değil.

Jeppe Stig Nielsen'in dediği gibi , bu konunun zaten harika cevapları var, ama bu oldukça belirgin incelikten de bahsetmeye değer olduğunu düşündüm.

using ad alanlarında belirtilen yönergeler, dışarıda belirtildikleri gibi tam olarak kalifiye olmaları gerekmediğinden daha kısa kodlar oluşturabilir.

Türleri çünkü Aşağıdaki örnek çalışır Foove Baraynı genel ad ikisi de, Outer.

Foo.cs kod dosyasını varsayalım :

namespace Outer.Inner
{
    class Foo { }
}

Ve Bar.cs :

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

Bu, usingdirektifin dış ad alanını kısaca göz ardı edebilir :

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

Karşılaştığım bir kırışıklık (diğer cevaplarda yer almıyor):

Bu ad alanlarına sahip olduğunuzu varsayalım:

• Başka bir şey
• Parent.Something.Other

Kullandığınızda using Something.Other dışında a'nınnamespace Parent , ilki (Something.Other) ifade eder.

Ancak içeride kullanırsanız bu ad alanı bildirimi kullanırsanız, ikincisine (Parent.Something.Other)!

Basit bir çözüm var: " global::" önekini ekleyin : docs

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

Teknik nedenler cevaplarda tartışılıyor ve bence sonuçta kişisel tercihlere geliyor çünkü fark o kadar büyük değil ve her ikisi için de ödünler var. Visual Studio'nun .csdosya oluşturma varsayılan şablonu using, ad alanlarının dışındaki yönergeleri kullanır ;

Aşağıda , proje dosyasının kök dizinine dosya usingekleyerek, ad alanları dışındaki yönergeleri denetlemek için stylecop ayarlanabilir stylecop.json:

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

Bu yapılandırma dosyasını çözüm düzeyinde oluşturabilir ve yapılandırmayı tüm projelerinizde paylaşmak için 'Mevcut Bağlantı Dosyası' olarak projelerinize ekleyebilirsiniz.

Diğer cevapların kapsadığına inanmadığım bir başka incelik, aynı ada sahip bir sınıfınız ve ad alanınız olduğunda.

Ad alanının içinde içe aktarma yaptığınızda, sınıfı bulur. İçe aktarma ad alanının dışındaysa, içe aktarma yoksayılır ve sınıf ve ad alanının tam olarak nitelenmesi gerekir.

//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.
        }
    }
}

Bu eğer daha iyi bir uygulamadır varsayılan yani "seçeneğini kullanarak referansları ad ve olanları dışında olmalıdır kaynak çözümünde kullanılan" "Yeni eklenen referans" iyi bir uygulama size ad içine koymalıyız olmasıdır. Bu, hangi referansların eklendiğini ayırt etmektir.