Adlandırma türleri için iyi teknikler veya testler var mı?

Garip, açık bir soru, ancak bu her zaman çarptığım bir sorun:

Bakımı ve çalışması kolay olan yazılım, iyi tasarlanmış bir yazılımdır. Bir tasarımı sezgisel hale getirmeye çalışmak, bir sonraki geliştiricinin, bileşenin işlevini çıkarabilmesi için bileşenlerinizi adlandırmak anlamına gelir. Bu yüzden sınıflarımıza "Tip1", "Tip2" vb. İsimlerini vermeyiz.

Bir gerçek dünya konseptini modellerken (örn. Müşteri) bu genellikle gerçek dünya konseptini modellendikten sonra türünüzü adlandırmak kadar kolaydır. Ancak, daha sistem odaklı olan soyut şeyler inşa ederken, okunması kolay ve sindirimi kolay olan isimlerin tükenmesi çok kolaydır.

Bileşenlerin ne yapması gerektiğini açıklayan bir taban tipi veya ara yüz ile tür ailelerini adlandırmaya çalışırken (benim için) daha da kötüleşiyor. Bu, doğal olarak, uygulamanın lezzetini (örneğin IDataConnectionve SqlConnection.NET Framework'de) tanımlamaya çalışan her türetilmiş türe yol açar , ancak "yansıtma ve belirli bir dizi öznitelik aramaya çalışarak " gibi karmaşık bir şeyi nasıl ifade edersiniz?

Sonra nihayet ne yapmaya çalıştığını açıkladığınızı düşündüğünüz tip için bir isim seçtiğinizde, meslektaşınız “WTF DomainSecurityMetadataProvidergerçekten yapıyor mu? ”

Bir bileşen için iyi niyetli bir isim seçmek için herhangi bir iyi teknik var mı, yoksa karışık isimler almadan bir bileşen ailesi oluşturmak için?

İsmin "iyi" olup olmadığı hakkında daha iyi bir fikir edinmek için bir isme uygulayabileceğim basit testler var mı ve diğerleri için daha sezgisel olmalı mı?

Adlandırmada, benim için çalıştığı kanıtlanmış altı teknik var:

1. isimleri icat etmeye çok zaman harcamak
2. kod yorumlar kullanın
3. yeniden adlandırmak için tereddüt etme
4. isimleri icat etmeye çok zaman harcamak
5. kod yorumlar kullanın
6. yeniden adlandırmak için tereddüt etme

PS. Eğer API’niz herkese açık olacaksa, yukarıdakiler bundan önce geçerlidir - çünkü, bildiğiniz gibi,

“Elmaslar gibi herkese açık API'ler sonsuza dek sürecek. Doğru yapma şansın var, bu yüzden elinden gelenin en iyisini yap ...” (Joshua Bloch, İyi Bir API Nasıl Tasarlanır ve Neden Önemlidir )

Temel testim, değişkenin işlevini yalnızca değişkendeki sözcükleri kullanarak tanımlayabilirseniz:

örneğin, DomainSecurityMetadataProvider "Etki Alanı Güvenliği Meta Verileri Sağlar" veya "Etki Alanı Güvenliği ile İlgili Meta Veriler Sağlar" ise, bu iyidir.

Ancak, kişiden kişiye değişen farklılıklar vardır:

örn. Benim için, original_team_code orijinal takımın kodudur, oysa başkası için takımın orijinal kodu olabilir. Bunlardan benim kişisel favorim olan, "Yardım Etmeyen Eski Bir Kod", "Bu ThreadUnsafe Eski Kod" için bir Muteks "değil," Yardım Etmeyen Eski Bir Mutex "olarak okuyamadığım ama bulamadığım" UnsafeLegacyMutex "idi.

Bu yüzden benim genişletilmiş sınavım değişkeni tahtaya / wiki / chat'e yazmak ve insanların ne anlama geldiğini tahmin etmelerini sağlamak.

Bir bileşen için iyi niyetli bir isim seçmek için herhangi bir iyi teknik var mı, yoksa karışık isimler almadan bir bileşen ailesi oluşturmak için?

Pek sayılmaz.

Ancak bir ipucu, "pasif ses" ten uzak durmaktır.

"DomainSecurityMetadataProvider" pasif. Fiil yok, hepsi isimler ve sıfatlar olarak kullanılan isimler.

"ProvideMetadataForDomainSecurity" daha etkin. Bir fiil var.

Nesneye yönelik programlama hepsi (gerçekten) isim-fiildir. İsim == nesne. Fiil == yöntemi. Yani bir sınıf adı genellikle çok "isimsiz" dir. Bu alışkanlığı kırmak ve fiil eklemeye başlamak zordur.

İsmin "iyi" olup olmadığı hakkında daha iyi bir fikir edinmek için bir isme uygulayabileceğim basit testler var mı ve diğerleri için daha sezgisel olmalı mı?

Evet. Sorunuzda mükemmel bir test tanımladınız. Başkalarına sor.

Eski günlerde buna "tasarım yolu" diyorduk. Bir şelale metodolojisinde büyük ve terliydi. Günümüzde, Çevik yöntemlerle, bir sınıfın yazarı ve kullanıcıları arasında yapılan sıradan bir işbirliği olmalıdır. Uzun sürmez (ve olmamalıdır). Testleri (ve kodu) yazmadan önce tasarımın ve isimlerin tartışılması şaşkınlık faktörünü azaltacaktır ve WTF'leri önleyebilir.

Eş anlamlılar sözlüğü kullanma

Sınıflarımı ve metotları tanımlamak için uygun kelimeleri bulmak için yeni bir gelişim yaparken çok sık eş anlamlılar sözlüğüne başvuracağım.

Öncelikle işlem mantığı içeren sınıflar

Öncelikle "EntityProvider", "EntityLocator" gibi bir isim-fiil yapısında çalışma yöntemleri sağlayan sınıfları adlandırmaya meyilliyim.

Bu sınıflar genellikle çok fazla devlet içermez.

Devlet içeren sınıflar

UI ekranları ve veri varlıkları genellikle durumsaldır ve bu yüzden bu sınıfları bir isim veya sıfat-isim modeliyle adlandırırım.

Örnekler: Kişi, Çalışan, CurrentEmployee, FormerEmployee

Yardımcı sınıflar

Yalnızca statik yöntemler içeren sınıflar genellikle "yardımcı program" sınıfları olarak kabul edilir, bu nedenle bunları sürekli olarak bir "Yardımcı Program" soneki ile adlandırırım.

Örnekler: NetworkUtilities, FileUtilities

Testler

Bir şeyin kötü adlandırılmış olup olmadığına karar vermek için iyi bir testim yok, ancak adında tek bir isim ve / veya tek bir fiil kullanmayı denemeyi öneririm, sonra bu isim / fiilin neyi doğru bir şekilde tanımlayıp tanımlamadığını düşünün. yeniden adlandırma

Adın yakalamadığı sınıf / yöntem hakkında daha fazla şey olduğunu düşünüyorsanız, o zaman sınıf / yöntemin yeniden denetlenmesi gerekebilir.

Alan Green ve Jeff Attwood , "Yönetici" ekiyle adlandırma sınıflarının kötülüklerini yazdılar. "Yönetici" teriminin aşırı kullanıldığını ve anlamlı bir şey iletemeyecek kadar belirsiz olduğunu savunuyorlar. Katılıyorum.

Jeff'in makalesi ayrıca Steve McConnell'in Code Complete'ten önerilen kılavuzların bir listesini sunar.

değişkenler

Son zamanlarda, "Of", "By", "For" vb. Edatları içeren daha uzun tanımlayıcı değişken / parametre adlarıyla denemeler yaptım. Bazı örnekler aşağıda gösterilmiştir:

string firstNameOfEmployee;

string lastNameOfEmployee;

// here I nimbly avoid worrying about whether to call it "Id" or "ID" :)
int idOfEmployee;

decimal amountForDeposit;

Account accountForDeposit;

Bu, Visual Studio'nun intellisense özelliği ile bu uzun isimleri yazmayı kolaylaştırarak iyi çalıştığını buluyorum. Ayrıca, değişken ad öneklerinin daha az çoğaltılması olduğunu (örn. PersonID, personFirstName, personLastName vs. idOfPerson, firstNameOfPerson, lastNameOfPerson), intellisense'i daha da faydalı kılan daha iyi bir "karma" sağladığını da biliyorum.

Sonra nihayet ne yapmaya çalıştığını tanımladığınızı düşündüğünüz tip için bir isim seçtiğinizde, meslektaşınız “WTF bu DomainSecurityMetadataProvider gerçekten yapıyor mu?”

Karmaşık ve etki alanına özgü bir sınıf için ne tür bir ad bekliyorsunuz? Bu, sınıf adınızı bir cümle yapmadan elde edeceği kadar iyidir (bu, herkesin tek bir sınıfa çok fazla sorumluluk verdiğinizi düşünmesini sağlayacaktır)

Sağlayıcıyı adından çıkarmayı düşünüyorum. Özellikle Meta Verilerden bahsediyorsa, herkes yansıma kullandığınızı zaten biliyor. Bir kelimeyi daha kısa ve öz hale getirebilirsin (veya başka bir kelimeye geçebilirsin - bu yazdıklarından bir tedarikçiden daha çok tüketici olur)

Sistemin bölümlerini tanımlamak için metaforları kullanın. Sadece yeni analojiler keşfetmeniz için değil, isimlendirmeyi kolaylaştıracak.

(Bunun güçlü bir örnek olmadığını biliyorum ama yine de) Örneğin mailbox, bir sınıf için alınan iletiler için bir sıra işlevi gören bir değişken veya tür olarak çağırabilirsiniz .

Çok katı olduğum bir şey, İsimlerin ASLA yanlış olmasına izin verilmemesi gerektiğidir . En iyi örnek, bazı yeniden faktörlendirme sırasında, çok sayıda kod değişti ve birkaç değişken, adlarının önerdiğinden başka bir şeyi ifade etmeye başladı.

Çok geçmeden, bir programcı yaşlarını harcıyordu ve çoktan çıkarılmış ve depolanmış belirli veri parçalarını ele almaya çalışan çok pahalı bazı veritabanı çağrıları kullanıyordu. Herşeyi yeniden adlandırdım ve birdenbire fazladan karmaşık ve hatalı bir mantığı kaldırabiliriz.

Umarım isimler hakkında çok fazla düşünmeniz gereken durumlar nadirdir. Bu gibi durumlarda, sınıfın ne yaptığını açıklayan bir paragraf yazmanız yeterlidir. İşlev içi yorumların veya işlev düzeyi yorumunun aksine, bir sınıfın birincil amacı nadiren değişir, bu nedenle yorumların eski haline gelme riski nispeten küçüktür. Yani birkaç paragraf yazma lüksüne sahipsin ya da sınıfın ne yaptığını açıklamak için ASCII'yi çiz.