Altını çizmek veya altını çizmemek, işte soru bu

İkili sürüm diğer çerçeve dilleri tarafından kullanılacaksa, özel alanların ön ekine C # 'da alt çizgi koymama konusunda herhangi bir sorun var mı? Örneğin, C # büyük / küçük harf duyarlı olduğundan, bir alanı "foo" ve genel özelliği "Foo" olarak çağırabilirsiniz ve sorunsuz çalışır.

Bunun VB.NET gibi büyük / küçük harfe duyarlı olmayan bir dil üzerinde herhangi bir etkisi olur mu, isimler yalnızca büyük / küçük harfe göre ayırt edilebiliyorsa, CLS uyumu (veya diğer) sorunları olur mu?

Hiçbir etkisi olmayacak .

CLS uyumlu kitaplıklar yazma tavsiyelerinin bir kısmı, yalnızca duruma göre farklılık gösteren iki genel / korumalı varlığa sahip OLMAMALIDIR , örn.

public void foo() {...}

ve

public void Foo() {...}

tarif ettiğiniz şey sorun değil çünkü özel öğe kitaplığın kullanıcısı tarafından kullanılamıyor

ÖNEMLİ GÜNCELLEME (12 Nisan 2016):

NET CoreFX ekibinin dahili standardının, neden olduğuna dair herhangi bir fikir vermeden alt çizgi gösterimini kullanmakta ısrar ettiği dikkatimizi çekti . Biz kural 3. yakından bakmak Ancak eğer bir sistem olduğu ortaya çıkıyor _, t_, s_neden önerir öneklerle _ilk etapta seçildi.

3. Biz kullanmak _camelCaseiç ve özel alanlar için ve nerede salt okunur mümkün kullanın. Örnek alanları önek _, statik alanlar ile s_ve statik alanlar ile iş parçacığı t_. Statik alanlarda kullanıldığında, readonlysonra gelmelidir static(yani static readonlydeğil readonly static).
4. this.Kesinlikle gerekmedikçe kaçınırız .

Dolayısıyla , performans açısından kritik, çok iş parçacıklı, sistem düzeyinde kodlar üzerinde çalışan .NET CoreFX ekibi gibiyseniz , o zaman şunları yapmanız ŞİDDETLE ÖNERİLİR:

• kodlama standartlarına bağlı kalmak ve
• alt çizgi gösterimini kullanın ve
• bu cevabı daha fazla okumayın

Aksi takdirde lütfen okumaya devam edin ...

ORİJİNAL CEVAP:

Önce neden bahsettiğimiz konusunda anlaşalım. Sorun, görünürlük değiştiriciler izin veriyorsa, örnek üyelerine statik olmayan yöntemler ve bir sınıfın / alt sınıfların yapıcılarından nasıl erişeceğimizdir.

Underscore-notasyonu

• özel alanların adlarında "_" ön ekini kullanmanızı önerir
• ayrıca kesinlikle gerekli olmadıkça "bunu" kullanmamanız gerektiğini söylüyor

Bu gösterimde

• her zaman "bunu" kullanmanızı önerir. herhangi bir örnek üyesine erişmek için

Bu gösterim neden var?

Çünkü sen böyle

• aynı adı paylaştıklarında bir parametreyi bir alandan ayırmak
• mevcut örnek bağlamında çalıştığınızdan emin olun

Misal

public class Demo
{
   private String name;
   public Demo(String name) {
       this.name = name;
   }
}

Alt çizgi gösterimi neden var?

Bazı insanlar "bu" yazmayı sevmezler, ancak yine de bir alanı ve bir parametreyi ayırt etmek için bir yönteme ihtiyaç duyarlar, bu nedenle bir alanın önünde "_" kullanmayı kabul ettiler

Misal

public class Demo
{
   private String _name;
   public Demo(String name) {
      _name = name;
   }
}

Kişi bunun sadece kişisel zevk meselesi olduğunu ve her iki yolun da eşit derecede iyi / kötü olduğunu düşünebilir. Bununla birlikte, bu gösterimin alt çizgi gösterimini geçtiği bazı yönler vardır:

berraklık

• altçizgi notasyonu isimleri karıştırır
• this-notation isimleri olduğu gibi tutar

Bilişsel yük

• Alt çizgi notasyonu tutarsızdır, alanları özel bir şekilde ele almanızı sağlar, ancak bir mülke veya bir alana ihtiyacınız olup olmadığını kendinize her sormanız gerektiğinde diğer üyelerle birlikte kullanamazsınız.

• bu notasyon tutarlı, düşünmek zorunda değilsiniz, sadece herhangi bir üyeye atıfta bulunmak için her zaman "this" i kullanıyorsunuz

GÜNCELLEME: belirtildiği gibi aşağıdakiler bir avantaj noktası değildir

Bakım

• Altçizgi notasyonu, _yeniden düzenleme yaparken göz kulak olmanızı gerektirir , örneğin bir alanı özelliğe dönüştürmek (kaldır _) veya tersini (ekle _)

• bu notasyonun böyle bir sorunu yok

Otomatik tamamlama

Örnek üyelerinin listesini görmeniz gerektiğinde:

• Alt çizgi notasyonu size pek yardımcı olmaz, çünkü "_" yazdığınızda otomatik tamamlama açılır penceresi size özel alanları ve diğer örnek üyeleriyle karışık bağlantılı derlemelerde bulunan tüm türleri gösterir.
• Bu notasyon size net bir cevap verir, "bu" yazarak tüm gördüğünüz üye listesidir, başka hiçbir şey görmez

belirsizlik

Bazen Intellisense'in yardımı olmadan kodla uğraşmanız gerekir. Örneğin, kod incelemeleri yaptığınızda veya kaynak koda çevrimiçi olarak göz attığınızda.

• Alt çizgi notasyonu belirsizdir: Something.SomethingElse'i gördüğünüzde, Something'in sınıf olup olmadığını ve SomethingElse'nin statik özelliği olup olmadığını söyleyemezsiniz ... ya da Something, SomethingElse'nin kendi özelliğine sahip geçerli bir örnek özelliğidir.

• this-notation açıktır: Something.SomethingElse'i gördüğünüzde, yalnızca statik bir özelliği olan bir sınıf anlamına gelebilir ve bunu gördüğünüzde.Something.SomethingElse, Something'in bir üye ve SomethingElse'nin özelliği olduğunu bilirsiniz.

Uzatma yöntemleri

"This" kullanmadan örneğin kendisinde uzantı yöntemlerini kullanamazsınız.

• Alt çizgi gösterimi "this" kullanmamanızı gerektirir, ancak uzantı yöntemlerinde
• bu not sizi tereddüt etmekten kurtarır, her zaman "bu" noktasını kullanırsınız.

Visual Studio desteği

• Alt çizgi notasyonu, Visual Studio'da yerleşik bir desteğe sahip değildir

• this-notation, Visual Studio tarafından doğal olarak desteklenir:

  1. "Bu." Nitelendirme : Statik olmayan yöntemlerde kullanılan tüm statik olmayan alanları this.C # ile önceden eklenmesini tercih eder

Resmi tavsiyeler

Özellikle C # 'da açıkça "alt çizgi kullanmayın" diyen birçok resmi yönerge vardır.

• Alt çizgi notasyonu , adlandırma çakışmalarını önlemeye yardımcı olan genel bir uygulama olan C ++ 'dan gelmiştir, ayrıca VisualBasic.Net için bir alan "değeri" ve bir "Değer" özelliğinin aslında aynı ada sahip olduğu bir sorunun üstesinden gelmesi önerilir, çünkü VisualBasic büyük / küçük harfe duyarlı değildir

  1. Visual Basic'te bildirilen öğe adları
  2. VisualBasic.NET'te alanları yedekleme

• Bu gösterim C # için tavsiye edilirken "_" açıkça yasaklanmıştır:

  1. bu anahtar kelime C #
  2. Alan kullanım yönergeleri : Alan adlarına veya statik alan adlarına önek uygulamayın.
  3. Adları için yönergeleri: tip üyelerinin isimleri : alan adları için bir önek kullanmayın.
  4. Genel adlandırma kuralı : X Alt çizgi, kısa çizgi veya alfanümerik olmayan diğer karakterleri KULLANMAYIN
  5. Kalite onaylama kuralı CA1707 : Tanımlayıcılar alt çizgi içermemelidir
  6. Alt çizgi kullanmak CLS uyumlu değildir (genel ve korumalı tanımlayıcılar için)
  7. .NET Framework geliştiricilerinin iç adlandırma kuralı : Üye değişkenler için bir önek kullanmayın. Yerel ve üye değişkenler arasında ayrım yapmak istiyorsanız, "this" kullanmalısınız. C # ve "Ben" de. VB.NET'te.

Microsoft StyleCop Yardım dosyasından alınmıştır:

TypeName: FieldNamesMustNotBeginWithUnderscore

Kontrol Kimliği: SA1309

Neden: C # 'daki alan adı bir alt çizgiyle başlar.

Kural Açıklaması:

Bu kuralın ihlali, bir alan adı alt çizgiyle başladığında ortaya çıkar.

StyleCop varsayılan olarak yerel sınıf alanlarını işaretlemek için alt çizgi, m_, vb. Kullanılmasına 'bu' lehine izin vermez. önek. "Bunu" kullanmanın avantajı. kodu görüntülemek için hangi düzenleyicinin kullanıldığına bakılmaksızın, sınıf üyelerine yapılan tüm çağrıları anında tanınabilir hale getirerek, yöntemler, özellikler vb. dahil olmak üzere tüm öğe türlerine eşit şekilde uygulanmasıdır. Diğer bir avantajı, örnek üyeleri ile statik üyeler arasında önek eklenmeyecek hızlı, tanınabilir bir farklılaşma oluşturmasıdır.

Alan veya değişken adının Win32 veya COM ile ilişkili bir öğenin adıyla eşleşmesi amaçlanıyorsa ve bu nedenle bir alt çizgiyle başlaması gerekiyorsa, alanı veya değişkeni özel bir NativeMethods sınıfına yerleştirin. Bir NativeMethods sınıfı, NativeMethods ile biten bir adı içeren herhangi bir sınıftır ve Win32 veya COM sarmalayıcıları için bir yer tutucu olarak tasarlanmıştır. Öğe bir NativeMethods sınıfına yerleştirilirse StyleCop bu ihlali yok sayar.

Farklı bir kural açıklaması, yukarıdakilere ek olarak tercih edilen uygulamanın özel alanları küçük harflerle ve genel alanları büyük harflerle başlatmak olduğunu belirtir.

Düzenleme: Bir takip olarak, StyleCop'un proje sayfası burada bulunur: https://github.com/DotNetAnalyzers/StyleCopAnalyzers . Yardım dosyasını okumak, neden çeşitli stil kuralları önerdiklerine dair birçok fikir verir.

Özel bir alandan bahsettiğimiz için, sınıfınızın bir kullanıcısını etkilemez.

Ancak özel alan için bir alt çizgi kullanmanızı tavsiye ederim çünkü kodun anlaşılmasını kolaylaştırabilir, örneğin:

private int foo;
public void SetFoo(int foo)
{
  // you have to prefix the private field with "this."
  this.foo = foo;

  // imagine there's lots of code here,
  // so you can't see the method signature



  // when reading the following code, you can't be sure what foo is
  // is it a private field, or a method-argument (or a local variable)??
  if (foo == x)
  {
    ..
  }
}

Ekibimizde, özel alanlar için her zaman bir alt çizgi öneki kullanırız. Böylelikle bazı kodları okurken, özel alanları çok kolay bir şekilde belirleyebilir ve bunları yereller ve argümanlardan ayırabilirim. Bir bakıma, alt çizgi "bu" nun kısaltılmış hali olarak görülebilir.

O zamandan beri çok spesifik ve çok anlamsız stil kuralları olan bir ortamda çalıştıktan sonra kendi tarzımı yaratmaya başladım. Bu, çok fazla ileri geri attığım bir tür. Sonunda, özel alanların her zaman _field olacağına, yerel değişkenlerin hiçbir zaman _ olmayacağına ve küçük harf olacağına, kontroller için değişken adlarının Macar gösterimini gevşek bir şekilde takip edeceğine ve parametreler genellikle camelCase olacağına karar verdim.

this.Anahtar kelimeden nefret ediyorum , bence çok fazla kod gürültüsü ekliyor. Resharper'ın bunu gereksiz yere kaldırmasını seviyorum. Anahtar kelime.

6 yıllık güncelleme:Dictionary<TKey,T> Eşzamanlı erişimin belirli bir kullanımı için dahili özelliklerini analiz ediyordum ve özel bir alanı yerel bir değişken olarak yanlış okudum. Özel alanlar kesinlikle yerel değişkenlerle aynı adlandırma kuralı olmamalıdır. Bir alt çizgi olsaydı, inanılmaz derecede açık olurdu.

Alt çizgiyi beğendim, çünkü o zaman küçük harfli adı aşağıdaki gibi yöntem parametreleri olarak kullanabilirim:

public class Person
{
    string _firstName;

    public MyClass(string firstName)
    {
        _firstName = firstName;
    }

    public string FirstName
    {
        get { return _firstName; }
    }
}

Martin'in bahsettiği nedenle özel alanların önünde alt çizgi kullanmayı gerçekten seviyorum ve ayrıca özel alanlar daha sonra IntelliSense'te birlikte sıralanacak. Bu, genel olarak Macar önek gösterimlerinin kötülüğüne rağmen.

Bununla birlikte, son zamanlarda özel üyeler için alt çizgi önekini kullanmanın nedenini tam olarak bilmesem de hoş karşılanmadığını görüyorum. Belki başkası biliyordur? Bu sadece önek prensibi mi? Yoksa, derlenmiş derlemelerde alt çizgileri olan jenerik türlerin adlarının karıştırılmasıyla ilgili bir şey var mıydı?

Style Cop önerisi olsun ya da olmasın, .NET Framework'e bakıldığında üye değişkenleri için çok sayıda "_" kullanımı görülür. Style Cop yaratıcılarının önerdiği şey, MS çalışanlarının çoğunluğunun kullandığı şey değil. :) Bu yüzden alt çizgiye bağlı kalacağım. Kişisel olarak alt çizgiyi kullanarak bundan çok daha az hata yaptığım için (örnek: this.varName = varName yerine varName = varName kullanmak, gerçekten içimde kaldı)

Bence sınıf düzeyindeki alanların büyük ölçüde dilin tasarımında bir hata olduğunu düşünüyorum. C # 'ın özelliklerinin kendi yerel kapsamları olsaydı bunu tercih ederdim:

public int Foo
{
   private int foo;
   get
   {
      return foo;
   }
   set
   {
      foo = value;
   }
}

Bu, alanları tamamen kullanmayı bırakmayı mümkün kılar.

Özel bir alanın önüne alt çizgi koyduğum tek zaman, bir özelliğin ayrı bir destek alanı gerektirdiği zamandır. Bu aynı zamanda özel alanları kullandığım tek zamandır . (Ve korumalı, dahili veya genel alanları asla kullanmadığım için, alanları dönemini kullandığım tek zaman budur.) Bana kalırsa, bir değişkenin sınıf kapsamına sahip olması gerekiyorsa, bu sınıfın bir özelliğidir.

Özel alanlar için _fieldName gösterimini kırmak çok kolaydır . Bunu kullanarak." notasyonu kırmak imkansızdır. _ Notasyonunu nasıl kırarsınız? Gözlemek:

private void MyMethod()
{
  int _myInt = 1; 
  return; 
}

İşte böyle, ben sadece adlandırma kuralınızı ihlal ettim ama derleniyor. A) Macarca olmayan ve b) açık bir adlandırma kuralına sahip olmayı tercih ederim. Macarca isimlendirmeyi ortadan kaldırmaktan yanayım ve bu bir şekilde nitelendiriyor. Değişken adının önündeki bir nesnenin türü yerine, onun erişim düzeyine sahipsiniz.

Bunu, değişkenin @my_numberadının adı kapsama bağladığı ve kırılamaz olduğu Ruby ile karşılaştırın .

düzenleme: Bu cevap olumsuz oldu. Umrumda değil, kalıyor.

Derlemenizin CLS uyumlu olmasını istediğinizde, assemblyinfo dosyanızda CLSCompliant özniteliğini kullanabilirsiniz. Derleyici, kodunuz cls uyumlu olmayan şeyler içerdiğinde şikayet eder.

Daha sonra, yalnızca duruma göre farklılık gösteren 2 özelliğiniz olduğunda, derleyici bir hata verecektir. Öte yandan aynı sınıfta özel bir alanınız ve bir kamu mülkünüz olduğunda herhangi bir sorun olmayacaktır.

(Ancak, özel üyelerimin önüne her zaman bir alt çizgi koyarım. Ayrıca kodumu okuduğumda belirli bir değişkenin üye alanı olduğunu netleştirmeme yardımcı olur).

Özel alanlarımın önünde alt çizgi kullanmayı iki nedenden dolayı seviyorum. Birinden daha önce bahsedilmişti, alanlar kodda ve Intellisense'de ilişkili özelliklerinden ayrılır. İkinci neden, ister VB ister C # kodluyor olsam da aynı adlandırma kurallarını kullanabilmemdir.

Herhangi bir çıkarım yok. Kodunuz derlendiğinde, derleyici için önemli olan tek şey alanın / mülkün ad alanı ve görünürlüğüdür. Bir tanımlayıcıyı adlandırırken alt çizgi, diğer herhangi bir karakter kadar önemlidir. Gerçek numara, sizin ve çevrenizdeki insanların anlayacağı bir kongre kullanmaktır.