Microsoft neden parametreleri, yerel değişkenleri ve özel alanları aynı ad adlandırma kuralına sahip yaptı?

Bu soruyu bir süre önce sordum: Özel değişkenlerinizi C # olarak nasıl adlandırıyorsunuz?

Yanıtlardan birinde, özel değişkenlerin / alanların şu şekilde adlandırılması gerektiğini gösteren Microsoft'un MSDN sayfasına yönlendirildim:

private int myInteger;

Ancak bir parametre şöyle olur:

void SomeMethod(int myInteger)

ve yerel bir değişken şöyle olur:

int myInteger;

Yani onlara böyle referans verdiğinizde

myInteger = 10;

hangisinden bahsettiğinizi bilmenin hiçbir yolu yok.

Şimdi yeni bir projeye başlıyorum ve iş arkadaşlarımdan biri bana bunlardan en azından bazılarını ayırt etmek için neden bir şey yapmadığımızı soruyor.

Aynı şeyi merak ediyorum. Microsoft'un standardı neden bunları farklı tutmadı?

Orijinal adlandırma kurallarının sınıf üyeleri için bir m_ öneki vardı, bu basit bir alt çizgiye indirgendi. Alt çizgi öneki kullanarak çok daha eski bir C # Microsoft kodu görürsünüz. Ancak, bir kez Tech Ed'de önde gelen alt çizginin CLS uyumlu olmadığını duydum. Bunun daha basit bir isim-hepsine uyar şemasına geçmelerinin nedeni olduğunu varsayıyorum. VB.Net'in büyük / küçük harf duyarsız isimlerinin de CLS uyumlu olmadığı (şimdi emin değilim).

Ne için değer, ben hala sınıf üyeleri için önde gelen alt çizgi kullanın. Bunu (adın aksine this.name) kullanarak netleştirebilmenize rağmen, hatalar hala geçer.

MS'in size söyleyeceği her şeyi yapmak zorunda değilsiniz.

localve parameterdeğişkenler aynı şekilde adlandırılır çünkü kapsamları aynıdır

Özel değişkenlere gelince, bu konuda farklı görüşler vardır. Her zaman burada bulunan , _özel değişkenlerden önce bir lider kullanmayı belirten standartları kullandım , ancak yazar _biraz tartışmalı olduğunu ve Microsoft'un buna karşı önerdiğini söylüyor .

Wikipedia , C ve C ++ 'da

Çift alt çizgi veya alt çizgi ile başlayan isimler uygulama için ayrılmıştır (derleyici, standart kütüphane) ve kullanılmamalıdır (örneğin __reserved veya _Reserved).

belki de birçok Microsoft geliştiricisinin _zaten kendi özel değişkenleri için bir önek kullandığı oldukça iyi bilinmesine rağmen, Microsoft'un buna karşı önerilmesinin ardındaki neden buydu .

Onları neden farklı tutmadıklarını söyleyemem. Standartları oluşturmaya katılan biri bu soruyu görmezse kimse yapamaz.

Birçok kişi, örnek değişkenlerini önek olarak ekleyerek kendi kurallarını oluşturur _ veyam_ , ancak gerçekten önemli olduğunu düşünmüyorum. Bağlamdan çok şey çıkarabilirsiniz ve bu günlerde IDE'ler size yardımcı olacak kadar akıllıdır. Örneğin, ReSharper eklentisine sahip Visual Studio, yerel değişkenleri ve örnek değişkenleri farklı renklerde gösterecektir.

İki kapsamı birbirinden ayırmanız gerçekten önemliyse, this. örnek değişkenine başvurmak için öneki :

public class Test
{
    private int myInteger;

    void SomeMethod(int myInteger)
    {
        this.myInteger = 10; // sets instance variable to 10
        myInteger = 10; // does not affect the instance variable.
    }
}

Başka eklenti olmadan, Visual Studio varsayılan olarak Intellisense ile size yardımcı olacaktır:

(Pop-up hala ReSharper tarafından şekillendirilmiş olabilir, ancak ReSharper yerleşik Intellisense özelliklerine hiçbir şey eklemez, bu nedenle stok biraz farklı görünebilir, ancak yine de orada her iki seçenek de olacaktır. )

Değişken adlandırma ve kapsamla ilgili olası sorunları yakalamanıza yardımcı olması için FxCop ve StyleCop gibi kod analiz araçlarını da kullanabilirsiniz .

Microsoft'un standardı neden bunları farklı tutmadı?

Microsoft'taki insanlar, bazı şeylerin neden deve kaplaması ve diğerleri paskal kaplaması da dahil olmak üzere bir dizi konvansiyonu açıklayan Çerçeve Tasarım Yönergeleri adlı bir kitap yazdı. .

Düzenle (kitaptan ayrıntı ekleyerek):

Kitapta, kullanılabilirlik çalışmaları yapmanın yanı sıra Turbo Pascal grubunu edinmekten öğrenilen bazı derslerden bahsediyorlar. Ayrıca, tüm diller büyük / küçük harfe duyarlı olmasa da (VB gibi), diğerleri (C # gibi) olduğundan, birinin adlandırmasında tutarlı olması gerekir. Kişi, sadece maddeleri ayırt etmek için farklı olan durumlara bağlı olamaz. Çerçevenin geri kalanı tarafından kullanılan sözleşmelere sadık kalırsa, geliştiriciler tarafından daha az karışıklığa yol açacaktır.

Bölüm 3, Adlandırma Yönergeleri.
Bölüm 3.1 büyük harf kullanım sözleşmeleridir.

camelCasingparametre adları içindir.
PascalCasingad alanı, tür ve üye adları içindir. Adın bir parçası olarak 2 harfli kısaltmalar olması durumunda, bunları büyük harfle bir arada tutunIOStream .

Bölüm 3.5 sınıfları, yapıları ve arayüzleri adlandırmayı kapsamaktadır.
Bölüm 3.6, isimlendirme türü üyelerini kapsar.
Bölüm 3.7, adlandırma parametrelerini kapsar.

Çünkü yazıldığı ortama bağlı oldukları için oldukça ayırt edilebilirler.

Örneğin, üye değişken olarak hiç parametre kullandınız mı? Veya parametre olarak yerel bir değişken? Yerel değişken olarak bir üye değişkene ne dersiniz?

• Tüm üye değişkenler bir sınıfın "gövdesinde" bulunur. thisBenzer bir ada sahip yerel bir değişkenten ayırt etmek için kullanabileceğiniz zaman üyeye ön ek yapmanız gereken argümanı satın almıyorum , aksi takdirde gerekli değildir.

• Yerel değişken ayrıca yalnızca bir yöntemin kapsamı içinde veya bir kod bloğu kapsamı içinde tanımlanır.

• Bir parametre her zaman yöntem imzasında tanımlanır.

Bu tür değişkenlerin hepsini karıştırırsanız veya karıştırırsanız, daha okunabilir veya keşfedilebilir hale getirmek için kod tasarımınız hakkında gerçekten daha fazla düşünmelisiniz. Onlardan daha iyi ve daha açıklayıcı adlar verin myInteger.

Microsoft standartları hakkındaki sorunuza cevap veremiyorum. Bir standardın bu şeyleri ayırt etmesini istiyorsanız, PL / SQL parametreleri için kullandığım standart, parametre adının önüne,,,,, için in_, out_ve io_dışında için parametrelerin önüne gelir . Bir işlevin yerel değişkenleri a ile başlar v_.

Tanıdığım çoğu şirket, üye değişkenleri için önek olarak alt çizgi veya küçük harf m ("üye" için) belirten kodlama standartlarına sahiptir.

Yani

_varName

veya

mVarName

Diğer insanların işaret ettiği gibi, genellikle öğenin hangi kapsamda kullanıldığını söyleyebilirsiniz. Parametreyi ve yerel değişkeni aynı kapsamda tutamazsınız ve özel değişkeni istiyorsanız, this.myInteger öğesini kullanın. Bu yüzden Microsoft'un bu konuda çok endişeli olduğunu düşünmüyorum, çünkü isterseniz aralarında kolayca ayrım yapabilirsiniz.

Ancak, henüz kimsenin bunu söylemediğine biraz şaşırdım, ancak Microsoft'u ve adlandırma kurallarını unutun (bir toplantıya koşmak zorunda kalmadan ve bunu göndermeden açık bıraktığımdan beri birisi bunu söylemiş olabilirdi) o). Macarca gösterim de Microsoft'ta başlatılan bir adlandırma kuralıydı (ya da Xerox muydu? Simonyi'nin ne zaman geldiğini hatırlayamıyorum). Bu güne kadar Macarca gösterimin adını lanetlemediğini bildiğim kimseyi düşünemiyorum. İçinde kullandığımız kendi standardımızla geldiğimiz yerde çalıştığımız için çok rahatsız olduk. Bize daha mantıklı geldi ve çalışmalarımızı biraz hızlandırdı (aslında Microsoft'un şimdi önerdiğine oldukça yakındı, ancak özel değişkenler hariç her şey paskal bir durumdu).

Bununla birlikte, Microsoft'un kullandığı daha yeni standart (deve çantası ve pascal kasa karışımı) çok kötü değil. Ancak siz ve iş arkadaşlarınız hoşunuza gitmiyorsa, kendi standartlarınızı oluşturun (topluca en iyisidir). Bu elbette şirketinizin zaten bir dizi standardı olup olmadığına bağlıdır. Eğer yaparlarsa, onlara sadık kalın. Aksi takdirde, siz ve iş arkadaşlarınız için neyin işe yaradığını bulun. Sadece mantıklı kal. '

Aaronaught, Charles Simonyi ve Macar Gösterimi hakkında alıntı istediğinden beri: http://en.wikipedia.org/wiki/Charles_Simonyi

http://en.wikipedia.org/wiki/Hungarian_notation

http://msdn.microsoft.com/en-us/library/aa260976(v=VS.60).aspx

http://ootips.org/hungarian-notation.html

http://www.hitmill.com/programming/vb/Hungarian.html

http://web.mst.edu/~cpp/common/hungarian.html

Son ikisi sadece Macarca gösterimin örnekleridir ve ootip bağlantısı, konuyla ilgili bazı görüşlere ilişkin bazı alıntılardır. Ayrıca sistem Macarca Notasyonu olduğunu unutmayın, ancak aynı zamanda, bildiğim kadarıyla, Microsoft programcılarının popülerliğine geldi (her ne kadar uygulama varyasyonu için Simonyi'nin aksine, kim olduğunu bilmiyorum).