Hangi isimlendirme kalıpları var? [kapalı]

Bazı isimler var, bu isimlere ulaşmak için kendinizi bulursanız, zaten bir şeyi batırdığınızı bilirsiniz.

Örneğin:

XxxManager
Bu kötü, çünkü bir sınıf, sınıfın ne yaptığını tanımlamalıdır. Sınıfın ne yaptığıyla ilgili olarak bulabileceğiniz en belirgin kelime "yönetmek" ise, sınıf çok büyüktür.

Başka ne adlandırma karşıtı paternler var?

Açıklığa kavuşturmak için, "hangi adların kötü olduğunu" sormuyorum - bu soru tamamen özneldir ve bunu cevaplamanın bir yolu yoktur. "Hangi isimlerin sistemdeki genel tasarım sorunlarını gösterdiğini" soruyorum. Diğer bir deyişle, kendinizi bir Xyz bileşenini çağırmak istediğinizi görürseniz, bu muhtemelen bileşenin kötü niyetli olduğunu gösterir. Ayrıca burada her kuralın istisnaları olduğunu unutmayın - yalnızca bir tasarımı gerçekten durdurup yeniden düşünmem gerektiğine dair uyarı bayrakları arıyorum.

Aşağıdaki adlandırma karşıtı kalıplar .NET ve özellikle C # ile ilgilidir:

• Tutarsızlıklar . Eğer bir lider çizgi ile her alan adını başlatmaya karar verirse, ona sopa .
• Ambiguos, ünlü harflerin eksik olduğu kısaltmalardır . Alan adlarını ciddiye aldım cxtCtrlMngr. Bunun neye dayanması gerektiğini tahmin bile edemezsiniz.
• Çok uzun ve ayrıntılı değişken adları . ILoginAttemptRepositoryiyi ve açıklayıcı - ILoginAttemptRepositoryUsingEntityFrameworkForObjectRelationalMappingaçıklayıcı, ama kesinlikle iyi değil.

Sıklıkla karşılaştığım tek şey, basitçe, herhangi bir adlandırma modelini kullanmamaktır. Tipik olarak, geliştirici cehaletinin göstergesidir (isimlendirme modellerinin iyi bir şey olduğunu ) ve ayrıca bu anti-patern, bir sınıfla ilgili her tür metodu o sınıfın içine sokarak, yani bir Müşterinin türünü doldurarak, büyük ölçüde SRP'yi ihlal etme eğilimindedir. sınıfın özellikleri, CRUD yöntemleri, uygulamanın bir kısmının ihtiyaç duyduğu bir Müşteri ile uzaktan ilgili bir şey var.

Ayrıca "Engine" ifadesinin son ek olarak kullanılmasının "Manager" ile aynı olduğunu ekleyeceğim. Çok belirsiz ve denilen bir sınıf XxxEngine, VB tarzı bir Modül için bir miktar yöntem içeren bir şey olma eğilimindedir, bu nedenle nesne yönelimli programlama bilgisi olmadan, kullanımı kolay tek bir noktada bulunur.

Peki, basit cevaplar önce: Macarca yazın ( http://mindprod.com/jgloss/unmainnaming.html , ayrıca bazı harika fikirler var. Macarca kötülük olmadığı zaman daha dengeli bir bakış açısı, http://www.joelonsoftware.com /articles/Wrong.html )

Bir arabirim adına 'I' veya soyut bir sınıf adına 'Özet' öneki. Bu , soyut sınıflar kavramına sahip olmayan veya arayüzler ile soyut sınıflar arasında ayrım yapmayan dillerde münhasır olabilir - fakat Java'da, örneğin, her zaman kötü bir fikirdir.

Ayrıca, Müdür olayı konusunda seninle aynı fikirde değilim. Bazen bu kalıbı kullanıyorum ve bu sadece başka bir şeyi adlandırmaya kalkıştığımda, adın XxxxxManager'dan daha açıklayıcı olmayacağı anlamına geliyor. Bir veya iki kelimeyle özenle özetlenemeyen bazı görevler (zorunlu olarak karmaşık olanlar değil) vardır.

Speeling:

Eğik bir engelim var ve heceleyemiyorum. Yazım denetleyicisiyle, güçsüzüm. Oluşturduğum tüm isimleri, bir kelime işlemciye doğrulama için kopyalamaya çalışıyorum ama her zaman bazılarını özlüyorum. Son projemde api'nin büyük bir bölümünü yazdım ve sanırım ilk önce cevabı kelimesini kullandığımda çekimi hecelemedim ve hiç kimse bana söylemediği için doğru olduğunu varsaydım. Buna cevap veren en az 50 fonksiyonumuz vardı. Ekibe yeni bir kişi geldi ve neden cevap kullandığımızı sordu kendimi aptal hissettim.

Korkarım ki görüşlerim biraz tartışmalı. Ama deneyelim ...

Endişelendiğim kadarıyla Mike Baranczak ile aynı fikirdeyim, XxxController, XxxHandler gibi isimler gerçekten sık kullandığımız bir şey. Bizim için bir Denetleyici "kapsüllenmiş" bir şey için bir giriş noktası gibidir, örneğin işlemleri yönetmek, beklenmeyen hatalarla uğraşmak, asıl işi yapmak için XxxHandler'ı çağırmak. Bir XxxManager'ın bir denetleyicinin eş anlamlısı olduğunu söyleyebilirim. Bir durumda Yöneticisi, diğerini Denetleyici olarak kullanmamanın önemli olduğunu düşünüyorum. Bir takımda çalışıyorsanız tutarlı olmak çok önemlidir.

Böyle şeyler için daha iyi isimler bulmak gerçekten zor olurdu, ya da belki bile mümkün olmazdı. Durumun daha net olması için Xxx iyi seçilmiş olmalı.

Şahsen sevmediğim şey, get ... ya da set ... adındaki bir yöntemin basit bir erişimciden daha fazlası olması. Det'i seviyorum ... karar için.

Aklıma gelen başka bir şey var: Bob Amca'ya göre. Bir yöntem adındaki "Ve", çok şey yapmanın işaretidir. Fakat hayat her zaman sadece siyah ve beyaz değildir - tamam olduğunu düşündüğüm durumlar var - örneğin. Performans sorunları nedeniyle (neden onları işlememediğimizi kontrol etmek için verilere sahipseniz) ...

Şahsen ben de sistemlerin Macar gösterimini büyük bir hayranıyım - çoğu zaman bir IDE'de kaynak kod ile uğraşıyorsunuz. Fakat genellikle sadece bir editör kullanıyorsunuz ya da bir tarayıcıdaki repoyu geziyorsunuz. Bir dezavantaj, tip önekleri nedeniyle araç desteği olabilir ...

Bence en önemli şey arı yetiştirme yetkinliği - yetersiz bir kongre - benim için - kongre yapmamasından daha iyidir ...

Belki de en kötü adlandırma karşıtı model şudur:

create table stuff(..., foo1 string, bar1 string,
                        foo2 string, bar2 string, 
                        foo3 string, bar3 string, ...)

Üç elementli [foo, bar] çiftler listemiz var. Dördüncü bir ihtiyacımız olursa, tabloya yeni sütunlar eklemek zorunda kalacağız.

Böyle bir koda liderlik:

'SELECT foo' + i + ', bar' + i + ' FROM stuff'

Foo ve bar sütunları ile ayrı bir tablo oluşturulmalı ve malzeme tablosuna bağlanmalıdır:

create table fubar(foo string, bar string, stuff_id long)

İkinci en kötü durum şudur:

class Student {
  ...
  String homeStreet;
  String homeCity;
  String homeState;
  String permStreet;
  String permCity;    
  String permState;
  ...
}

Burada bir Address sınıfının iki örneği yerine altı alanımız var.

Bu anti-patern, iki grubun her bir kombinasyonunu listeleyen bir dizi iki parçalı isim ile işaretlenmiştir, örneğin [foo, bar] x [1,2,3] veya [home, perm] x [sokak, şehir, eyalet]

Bir totoloji olan herhangi bir sınıf veya arayüz isimlendirme, sadece bağlantının bahsettiği Java dilinde değil, herhangi bir dilde kötüdür.

Tautology (retorik), aynı şeyi söylemek için farklı kelimeler kullanarak bile tekrarlama netlik sağlamaz.

Sık sık, Libraryveya gibi genel adlara sahip yazılım kütüphaneleriyle karşılaşırım Common. En düşük tasarımı gösterir: geliştiriciler kod çoğaltmasından kaçınmak için çaba harcarlar, ancak işlevsellik temelinde ayrıştırılmış bir tasarım oluşturma girişiminde bulunmazlar.

Gönderen Microsoft adlandırma, ben kötü adları için bu listeyi sağlayabilir:

1. Anlambilimsel değiller; bu, ne yaptığına vurgu yapmak yerine, kullandığı teknolojiye veya temel aldığı kalıba vurgu yapan adlara sahip oldukları anlamına geliyor .
2. Sözdizimsel tutarlılığı takip etmezler. Örneğin, adların bir kısmı deve kasası, diğer kısmı ise paskal kasalıdır.
3. Bunlar zor kısaltmalar gibi anlamak vardır ScrollableX yerine CanScrollHorizontally
4. O ortamın anahtar kelimeleriyle uğraşacak şekilde seçildiler.