Değişken adlandırma kuralları? [kapalı]

Ben sadece (C # için) ReSharper kullanmaya başladım ve onun kodu bulucu kokuyor gibi, bana uzun bir süre önce (özellikle değişken adlandırma kuralları) düzeltmek istedim yazma hakkında bazı şeyler gösterir.

Yöntemler ve örnek değişkenler için bazı adlandırma kurallarımı yeniden gözden geçirmeme neden oldu. ReSharper, örnek değişkeninin daha düşük deve durumu olduğunu ve alt çizgiyle başladığını gösterir. Bir süre tüm yerel değişkenlerimi deve kasası haline getirmek istedim ama alt çizgi gerekli mi? Rahat buluyor musun? Bu sözleşmeyi sevmiyorum ama henüz denemedim, siz ne düşünüyorsunuz?

Tekrar değerlendirmemi sağlayan ikinci şey, GUI olay işleyicileri için adlandırma kurallarım. Ben genellikle ControlName_Action VS standart kullanın ve benim denetimleri genellikle Macarca gösterimi (bir son ek olarak, kullanıcı tarafından görülebilir ve benzer adlandırılmış değişken ile uğraşırken ne değil kod açıklığa yardımcı olmak için) kullanın, bu yüzden OK_btn_Click ( ), bunun hakkında ne düşünüyorsunuz? ReSharper sözleşmesine boyun eğmeli miyim yoksa eşit derecede geçerli başka seçenekler var mı?

ReSharper'ı, hangi adlandırma düzeni düzenini kullanırsanız kullanacak şekilde değiştirebilirsiniz. Olay işleyicilerini, alanları, özellikleri, çeşitli erişilebilirlik düzeylerine sahip yöntemleri vb. Özelleştirme dahil oldukça esnektir.

Aracın standartlarınızı tanımlamasına izin vermeyin - kendi standartlarınızı uygulamak için kullanın.

Güncelleme: İş yerinde çoğu özel şey için (değişkenler, alanlar ve argümanlar) daha düşük deve davası kullandığımızı söyledikten sonra. Yöntem adları, sabitler ve özellikler için üst deve durumu. Olay işleyicileri, kontrole özgü bir şey yerine temsil ettikleri eyleme göre adlandırılır - örneğin, HandleContinueButtonClick yerine HandleCustomerContinue. Bir süre ReSharper varsayılan şemasını denedim ve aslında umursamıyorum, gerçekten her iki şekilde de karışık değilim.

Göre

ancak alt çizgi gerekli mi? rahat buluyor musun

Alt çizgiyi kullanma konusunda çok sevdiğim bir şey, "bu" kullanımını önemli ölçüde azaltmasıdır.

Düşünmek:

public void Invoke(int size) {
    _size = size;
}

alt çizgi olmadan şunları yazmanız gerekir:

public void Invoke(int size) {
    this.size = size;
}

potansiyel olarak aşağıdakilerin ince hatasını ortaya koyar:

public void Invoke(int size) {
    size = size;    // urgh ... no this! 
}

Buna ek olarak, kod tamamlama daha kolaydır, çünkü sadece alt çizgiyi bağlayarak sadece özel alanların bir listesini alırken, "this" ile her şeyin bir listesini alırsınız.

Göre

genellikle Macarca gösterim kullanın

Çerçeve Tasarım Yönergeleri: Yeniden Kullanılabilir .NET kitaplıkları için Kurallar, Idoms ve Desenler diyor:

Macarca notasyonu KULLANMAYIN

Belirsizlik için az yer bırakmak :)

Tutarlılık gerçekten anahtardır. Bu ve netlik, yani şifreli olmayın veya her şeyi kısaltarak yazmayı kurtarmaya çalışmayın. Intellisense, şifreli (ama kısa!) İsimler değil, yazma tasarrufunuzdur.

C # 'da başlangıç ​​korumalı veya alt çizgi ile ortak ad Ortak Dil Belirtimi'ne karşıdır. Bu sadece özel üyeler için geçerlidir.

MSDN'den:

Uygulandıkları dilden bağımsız olarak diğer nesnelerle tam etkileşim için nesnelerin arayanlara yalnızca birlikte çalışmaları gereken tüm dillerde ortak olan özellikleri göstermesi gerekir. Bu nedenle, birçok uygulamanın ihtiyaç duyduğu bir dizi temel dil özelliği olan Ortak Dil Belirtimi (CLS) tanımlanmıştır.

Bkz. Http://msdn.microsoft.com/en-us/library/12a7a7h3.aspx

Burada alt çizgi hakkında uyarı okuyabilirsiniz:

Alt çizgi (_) ile başlayan öğe adları Ortak Dil Belirtimi'nin (CLS) bir parçası değildir, bu nedenle CLS uyumlu kod bu adları tanımlayan bir bileşeni kullanamaz. Ancak, bir öğe adındaki başka herhangi bir konumdaki bir alt çizgi CLS uyumludur.

Bkz. Http://msdn.microsoft.com/en-us/library/81ed9a62.aspx

Korunan üyeler sorun teşkil eder çünkü başka bir dilde yazılmış sınıftan miras alabilirsiniz.

Ancak CLS uyumlu kodlara ihtiyacınız yoksa sizin durumunuzda sorun olmayabilir.

Alt çizgileri severim. İlk bakışta değişkenin bir sınıf üyesi ve özel olduğunu biliyorsunuz.

Elbette IDE, fareyi üzerine getirdiğinizde "ilk bakış" ın yenemeyeceğini söyleyebilir. Yerel bir değişkenin ne olduğunu biliyorsunuz ve sadece gözlerinizle bir üye değişken nedir. Kaydırma veya fareyle üzerine gelme gerekmez.

"This" anahtar kelimesini kullanabilirsiniz, ancak _ daha iyi yatay taranabilirlik için daha kısadır. Açıklayıcı adlar genellikle istenir, ancak bir şey yerleşik bir kongre olduğunda 1 karaktere sahip olmak daha iyidir. örneğin, bir dizide döngü oluştururken dizin olarak i harfini kullanmak. İ'nin bir endeks olduğu belirlenmiş bir kural olduğundan, "i" nin ne anlama geldiğini merak etmeden taranabilirlik avantajından faydalanırsınız.

Genelde başkaları tarafından söylenenlere katılıyorum, ancak araçlar ve alet zincirleri söz konusu olduğunda, tembel ve kolay bir yaşam gibiyim. Hayatın sadece bunu yapmak için daha kolay olduğunu düşünüyorum. Nedenleri

• Kurulumu daha kolay (sadece varsayılanlarla git, hatta 20 kez Enter'a basabilir ve başlatabilirim)
• Hatalar genellikle varsayılan ayarlardan çıkarılmıştır, genellikle ilk kez bir kusur ortaya çıkaran ezoterik yapılandırmasıdır.
• Takım zinciri satıcısı muhtemelen benden daha fazla şey biliyor, bu nedenle bunu bir nedenden dolayı yaptılar. Uzmanların yanlış olduğuna kim karar vereceğim (Onları uzman olarak görüyorum, çünkü araçlarını aldım)
• Asla bir yönetici tarafından satıcıların seçimini savunmak zorunda kalmayacaksınız - "Ne tavsiye ediyorlar?"
• Yeni adam sizi "neden" ve "Bu şekilde daha iyi" ile rahatsız etmeyecek - Her cevap "çünkü onlar karar verdiler ..."

Yani benim şansım, sadece bir servet harcadığınız araçları yeniden yapılandırmak için geçerli bir neden bulabilirseniz , elbette bunu yapın. Değişiklik yapmayı haklı çıkaramazsan, yapma.

Her değişikliğin sürdürülmesi gereken (gerçek ve gizli) bir maliyeti olduğunu unutmayın. Ne kadar az olursa, maliyet o kadar düşük olur. Örneğin - bahsettiğim yeni adam - değişiklik yok, kullanım kılavuzunu okuyabileceği anlamına geliyor. Yeniden yapılandırın - zeyilnameyi yazmanız, diğer şeylerle birlikte saklamanız, emekli olmanız ve kılavuzunu okuduktan sonra okumasını sağlamanız gerekir. Belki 2 kişilik bir dükkan için sorun değil ama 100 kişilik bir dükkandan ne haber?

İstediğiniz iki kural, özel alan adlarının ve yöntem adlarının başındaki alt çizginin genel olarak C # geliştirme çevrelerinde norm olarak kabul edilir. Bu kurallara uyum sağlayarak, kodunuz diğer geliştiriciler için hemen daha anlaşılır olacaktır, çünkü bu, çalışmaya alıştıkları bir çerçevedir.

Denetimleriniz için Label, RadioButton, vb. Soneki genellikle norm olarak kabul edilir. Genellikle tek bir kavram (örneğin bir Etiket ve bir TextBox) için birden fazla kontrol bulunur ve bu sonek oldukça kullanışlıdır. Gerçek Macar notasyonu uzun zaman önce terk edildi, çünkü orijinal niyetini ifade etmeyen bir şeye piç haline getirildi, bu da ne tür, boyut vb. Değişkenle ilgili bağlamdı.

Benim durumumda, deve ve alt çizgi kullanarak tanımlayıcı (read: long) değişken adları ve kod tamamlama yardımcı olur. Visual Studio otomatik tamamlamanın nasıl çalıştığından emin değilim ama QtCreator'da ve daha az bir ölçüde Eclipse'de, örneğin

sDI

ve ...

someDescriptiveIdentifier

Gibi isimleriniz olması durumunda biraz yazarak kaydeder

someDescriptiveName, someOtherDescriptiveName, someOtherButNotTheSameDescriptiveName

hangi "açıklayıcı adlandırma modunda" üretmek eğilimindedir.

Alt çizgileri kullanarak otomatik olarak tamamlanmasını istediğim adı belirleyebilirim

someDescriptiveIdentifier

veya

_someDescriptiveClassMember

Umarım açıklamam yeterince açıktır :)