Haruskah arahan 'menggunakan' ada di dalam atau di luar namespace?

Saya telah menjalankan StyleCop pada beberapa kode C #, dan terus melaporkan bahwa usingarahan saya harus berada di dalam namespace.

Apakah ada alasan teknis untuk menempatkan usingarahan di dalam daripada di luar namespace?

Sebenarnya ada perbedaan (halus) antara keduanya. Bayangkan Anda memiliki kode berikut di File1.cs:

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

Sekarang bayangkan seseorang menambahkan file lain (File2.cs) ke proyek yang terlihat seperti ini:

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

Kompiler mencari Outersebelum melihat usingarahan - arahan di luar namespace, jadi ia menemukan Outer.Mathbukan System.Math. Sayangnya (atau mungkin untungnya?), Tidak Outer.Mathmemiliki PIanggota, jadi File1 sekarang rusak.

Ini berubah jika Anda meletakkan bagian usingdalam deklarasi namespace Anda, sebagai berikut:

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

Sekarang kompiler mencari Systemsebelum mencari Outer, menemukan System.Math, dan semuanya baik-baik saja.

Beberapa orang akan berpendapat bahwa itu Mathmungkin nama yang buruk untuk kelas yang ditentukan pengguna, karena sudah ada satu di dalamnya System; intinya di sini adalah hanya bahwa ada adalah perbedaan, dan itu mempengaruhi rawatan kode Anda.

Menarik juga untuk dicatat apa yang terjadi jika Fooada dalam namespace Outer, bukan Outer.Inner. Dalam hal ini, menambahkan Outer.MathFile2 memecah File1 terlepas dari mana using. Ini menyiratkan bahwa kompiler mencari namespace terlampir paling dalam sebelum melihat usingarahan apa pun .

Utas ini sudah memiliki beberapa jawaban yang bagus, tetapi saya merasa saya bisa membawa sedikit lebih detail dengan jawaban tambahan ini.

Pertama, ingat bahwa deklarasi namespace dengan titik, seperti:

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

sepenuhnya sama dengan:

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

Jika Anda mau, Anda bisa usingmengarahkan semua level ini. (Tentu saja, kami ingin memiliki usinghanya di satu tempat, tetapi akan sah menurut bahasa.)

Aturan untuk menyelesaikan jenis yang tersirat, dapat secara longgar dinyatakan seperti ini: Pertama mencari "lingkup" paling dalam untuk kecocokan, jika tidak ada yang ditemukan, keluar satu tingkat ke ruang lingkup berikutnya dan cari di sana, dan seterusnya , sampai kecocokan ditemukan. Jika pada tingkat tertentu lebih dari satu kecocokan ditemukan, jika salah satu jenis berasal dari rakitan saat ini, pilih yang itu dan keluarkan peringatan kompiler. Jika tidak, menyerah (kesalahan waktu kompilasi).

Sekarang, mari kita menjadi eksplisit tentang apa artinya ini dalam contoh nyata dengan dua konvensi utama.

(1) Dengan usings luar:

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

Dalam kasus di atas, untuk mengetahui apa jenisnya Ambiguous, pencarian dilakukan dalam urutan ini:

1. Jenis bersarang di dalam C(termasuk jenis tersarang yang diwarisi)
2. Ketik dalam namespace saat ini MyCorp.TheProduct.SomeModule.Utilities
3. Jenis dalam namespace MyCorp.TheProduct.SomeModule
4. Ketik dalam MyCorp.TheProduct
5. Ketik dalam MyCorp
6. Jenis dalam namespace nol (namespace global)
7. Jenis dalam System, System.Collections.Generic, System.Linq, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, danThirdParty

Konvensi lainnya:

(2) Dengan usings di dalam:

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

Sekarang, cari jenisnya Ambiguousdengan urutan ini:

1. Jenis bersarang di dalam C(termasuk jenis tersarang yang diwarisi)
2. Ketik dalam namespace saat ini MyCorp.TheProduct.SomeModule.Utilities
3. Jenis dalam System, System.Collections.Generic, System.Linq, MyCorp.TheProduct, MyCorp.TheProduct.OtherModule, MyCorp.TheProduct.OtherModule.Integration, danThirdParty
4. Jenis dalam namespace MyCorp.TheProduct.SomeModule
5. Ketik dalam MyCorp
6. Jenis dalam namespace nol (namespace global)

(Perhatikan bahwa MyCorp.TheProductitu adalah bagian dari "3." dan karena itu tidak diperlukan antara "4." dan "5.".)

Komentar penutup

Tidak masalah jika Anda menempatkan usings di dalam atau di luar deklarasi namespace, selalu ada kemungkinan bahwa seseorang nanti menambahkan tipe baru dengan nama yang identik ke salah satu ruang nama yang memiliki prioritas lebih tinggi.

Juga, jika namespace bersarang memiliki nama yang sama dengan tipe, itu dapat menyebabkan masalah.

Itu selalu berbahaya untuk memindahkan usings dari satu lokasi ke lokasi lain karena hirarki pencarian berubah, dan jenis lain dapat ditemukan. Karena itu, pilih satu konvensi dan patuhi itu, sehingga Anda tidak perlu pernah memindahkan usings.

Templat Visual Studio, secara default, menempatkan usings di luar namespace (misalnya jika Anda membuat VS menghasilkan kelas baru dalam file baru).

Satu (kecil) keuntungan memiliki usings di luar adalah bahwa Anda kemudian dapat menggunakan arahan penggunaan untuk atribut global, misalnya, [assembly: ComVisible(false)]bukan [assembly: System.Runtime.InteropServices.ComVisible(false)].

Menempatkannya di dalam namespaces membuat deklarasi lokal ke namespace untuk file tersebut (jika Anda memiliki beberapa namespaces dalam file) tetapi jika Anda hanya memiliki satu namespace per file maka itu tidak membuat banyak perbedaan apakah mereka pergi ke luar atau di dalam namespace.

using ThisNamespace.IsImported.InAllNamespaces.Here;

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

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

namespace Namespace3
{ 
   using ThisNamespace.IsImported.InJustNamespace3;
}

Menurut Hanselman - Menggunakan Petunjuk dan Pemuatan Majelis ... dan artikel-artikel serupa lainnya secara teknis tidak ada perbedaan.

Preferensi saya adalah menempatkannya di luar ruang nama.

Menurut Dokumentasi StyleCop:

SA1200: MenggunakanDirectivesMustBePlacedWithinNamespace

Penyebab AC # menggunakan arahan ditempatkan di luar elemen namespace.

Deskripsi Aturan Pelanggaran aturan ini terjadi ketika arahan menggunakan atau arahan using-alias ditempatkan di luar elemen namespace, kecuali file tersebut tidak mengandung elemen namespace.

Misalnya, kode berikut akan menghasilkan dua pelanggaran aturan ini.

using System;
using Guid = System.Guid;

namespace Microsoft.Sample
{
    public class Program
    {
    }
}

Namun, kode berikut tidak akan mengakibatkan pelanggaran apa pun terhadap aturan ini:

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

    public class Program
    {
    }
}

Kode ini akan dikompilasi dengan bersih, tanpa ada kesalahan kompiler. Namun, tidak jelas versi jenis Guid yang dialokasikan. Jika arahan penggunaan dipindahkan di dalam namespace, seperti yang ditunjukkan di bawah ini, kesalahan kompiler akan terjadi:

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

Kode gagal pada kesalahan kompilator berikut, ditemukan pada baris yang berisi Guid g = new Guid("hello");

CS0576: Namespace 'Microsoft.Sample' berisi definisi yang bertentangan dengan alias 'Guid'

Kode tersebut membuat alias ke tipe System.Guid yang disebut Guid, dan juga membuat tipe sendiri yang disebut Guid dengan antarmuka konstruktor yang cocok. Kemudian, kode menciptakan turunan dari tipe Guid. Untuk membuat instance ini, kompiler harus memilih antara dua definisi Guid yang berbeda. Ketika directive alias menggunakan ditempatkan di luar elemen namespace, kompiler akan memilih definisi lokal Guid didefinisikan dalam namespace lokal, dan sepenuhnya mengabaikan directive alias menggunakan yang didefinisikan di luar namespace. Sayangnya, ini tidak jelas ketika membaca kode.

Ketika menggunakan-alias direktif diposisikan dalam namespace, kompiler harus memilih antara dua jenis Guid yang berbeda dan saling bertentangan, keduanya didefinisikan dalam namespace yang sama. Kedua tipe ini menyediakan konstruktor yang cocok. Kompiler tidak dapat membuat keputusan, sehingga menandai kesalahan kompiler.

Menempatkan menggunakan-alias direktif di luar namespace adalah praktik yang buruk karena dapat menyebabkan kebingungan dalam situasi seperti ini, di mana tidak jelas versi jenis mana yang benar-benar digunakan. Ini berpotensi menyebabkan bug yang mungkin sulit didiagnosis.

Menempatkan arahan-alias menggunakan dalam elemen namespace menghilangkan ini sebagai sumber bug.

2. Banyak ruang nama

Menempatkan banyak elemen namespace dalam satu file umumnya adalah ide yang buruk, tetapi jika dan ketika ini dilakukan, itu adalah ide yang baik untuk menempatkan semua menggunakan arahan dalam setiap elemen namespace, daripada secara global di bagian atas file. Ini akan membatasi ruang nama secara ketat, dan juga akan membantu menghindari jenis perilaku yang dijelaskan di atas.

Penting untuk dicatat bahwa ketika kode telah ditulis dengan menggunakan arahan yang ditempatkan di luar namespace, harus berhati-hati ketika memindahkan arahan ini di dalam namespace, untuk memastikan bahwa ini tidak mengubah semantik kode. Seperti dijelaskan di atas, menempatkan arahan-alias menggunakan di dalam elemen namespace memungkinkan kompiler untuk memilih antara tipe yang saling bertentangan dengan cara yang tidak akan terjadi ketika arahan ditempatkan di luar namespace.

Cara Memperbaiki Pelanggaran Untuk memperbaiki pelanggaran aturan ini, pindahkan semua menggunakan arahan dan arahan menggunakan-alias di dalam elemen namespace.

Ada masalah dengan menempatkan pernyataan menggunakan di dalam namespace ketika Anda ingin menggunakan alias. Alias ​​tidak mendapat manfaat dari usingpernyataan sebelumnya dan harus sepenuhnya memenuhi syarat.

Mempertimbangkan:

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

    class MyClass
    {
    }
}

melawan:

using System;

namespace MyNamespace
{
    using MyAlias = DateTime;

    class MyClass
    {
    }
}

Ini dapat diucapkan secara khusus jika Anda memiliki alias bertele-tele seperti berikut ini (yang merupakan bagaimana saya menemukan masalah):

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

Dengan usingpernyataan di dalam namespace, tiba-tiba menjadi:

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

Tidak cantik.

Sebagai Jeppe Stig Nielsen mengatakan , thread ini sudah memiliki jawaban yang besar, tapi saya pikir kehalusan agak jelas ini layak disebut juga.

using arahan yang ditentukan di dalam ruang nama dapat membuat kode lebih pendek karena tidak perlu sepenuhnya memenuhi syarat seperti ketika mereka ditentukan di luar.

Contoh berikut berfungsi karena tipe Foodan Barkeduanya di namespace global yang sama Outer,.

Anggap file kode Foo.cs :

namespace Outer.Inner
{
    class Foo { }
}

Dan Bar.cs :

namespace Outer
{
    using Outer.Inner;

    class Bar
    {
        public Foo foo;
    }
}

Itu bisa menghilangkan namespace luar dalam usingdirektif, singkatnya:

namespace Outer
{
    using Inner;

    class Bar
    {
        public Foo foo;
    }
}

Satu kerutan yang saya temui (yang tidak tercakup dalam jawaban lain):

Misalkan Anda memiliki ruang nama ini:

• Sesuatu. Lainnya
• Induk. Sesuatu. Lainnya

Saat Anda menggunakan di using Something.Other luar a namespace Parent, itu mengacu pada yang pertama (Sesuatu. Lainnya).

Namun jika Anda menggunakannya di dalam deklarasi namespace itu, itu merujuk pada yang kedua (Parent. Sesuatu. Lainnya)!

Ada solusi sederhana: tambahkan global::awalan " ": docs

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

Alasan teknis dibahas dalam jawaban dan saya pikir itu pada preferensi pribadi pada akhirnya karena perbedaannya tidak begitu besar dan ada pengorbanan untuk keduanya. Template default Visual Studio untuk membuat .csfile menggunakan usingarahan di luar ruang nama misalnya

Orang dapat menyesuaikan stylecop untuk memeriksa usingarahan di luar ruang nama melalui menambahkan stylecop.jsonfile di root file proyek dengan yang berikut:

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

Anda dapat membuat file konfigurasi ini di tingkat solusi dan menambahkannya ke proyek Anda sebagai 'File Tautan yang Ada' untuk membagikan konfigurasi di semua proyek Anda juga.

Kehalusan lain yang saya tidak percaya telah tercakup oleh jawaban lain adalah ketika Anda memiliki kelas dan namespace dengan nama yang sama.

Ketika Anda memiliki impor di dalam namespace maka itu akan menemukan kelas. Jika impor di luar namespace maka impor akan diabaikan dan kelas dan namespace harus sepenuhnya memenuhi syarat.

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

Ini adalah praktik yang lebih baik jika standar yang digunakan yaitu " referensi " yang digunakan dalam solusi sumber Anda harus berada di luar ruang nama dan yang "baru ditambahkan referensi" adalah praktik yang baik adalah Anda harus meletakkannya di dalam namespace. Ini untuk membedakan referensi apa yang ditambahkan.