Başka kimseler adlandırma sınıflarını ve yöntemlerini programlamanın en zor kısımlarından biri bulabilir mi? [kapalı]

Bu yüzden bir web hizmeti aracılığıyla bir satıcıdan yardım belgeleri istemek gerekiyordu bu sınıf üzerinde çalışıyorum. Bunu isim deneyin DocumentRetriever, VendorDocRequester, DocGetterama sadece doğru gelmiyor. Yeterli bir kelime bulmaya çalışarak yarım saat boyunca dictionary.com'a göz attım .

Kötü isimlerle programlamaya başlamak, sabahları çok kötü bir saç gününe sahip olmak gibidir, günün geri kalanı oradan yokuş aşağı gider. Beni hisset?

Şu anda ne yaptığınız iyi ve şu andaki sözdiziminize bağlı kalmanızı şiddetle tavsiye ederim:

bağlam + fiil + nasıl

Ben bu yöntemi fonksiyonları / yöntemleri, SQL saklı procs, vb adlandırmak için kullanın. Bu sözdizimine uyarak, Intellisense / Kod Bölmeleri çok daha temiz tutacak. EmployeeGetByID () EmployeeAdd (), EmployeeDeleteByID () istersiniz. GetEmployee () gibi daha dilbilgisi açısından doğru bir sözdizimi kullandığınızda AddEmployee (), ilişkisiz şeylerle aynı sınıfta birden çok Gets'iniz varsa, bunun gerçekten dağınık olduğunu göreceksiniz.

Dosyaları tarihlerle adlandırmak için bunu sevdim, 2009-01-07.log 1-7-2009.log değil demek istersiniz çünkü bir sürü var sonra sipariş tamamen işe yaramaz hale gelir.

Öğrendiğim bir ders, bir sınıf için bir isim bulamazsanız, o sınıfta neredeyse her zaman yanlış bir şey var:

• ona ihtiyacın yok
• çok şey yapıyor

İyi bir adlandırma kuralı, herhangi bir değişken, sınıf, yöntem veya işlev için kullanabileceğiniz olası ad sayısını en aza indirmelidir. Tek bir olası ad varsa, bunu hatırlamakta asla zorluk çekmeyeceksiniz.

İşlevler için ve tekil sınıflar için, ben onun temel işlevi olup olmadığını görmek için işlevini inceleyerek dönüşümü şey başka türlü içine bir şey bir tür. Bu terimi çok gevşek kullanıyorum, ancak yazdığınız çok sayıda fonksiyonun bir formda bir şey alıp başka bir formda bir şey ürettiğini keşfedeceksiniz.

Sizin durumunuzda, sınıfınız bir URL'yi bir Belgeye dönüştürdüğü anlaşılıyor . Bunu bu şekilde düşünmek biraz garip, ama mükemmel bir şekilde düzeltildi ve bu modeli aramaya başladığınızda, her yerde göreceksiniz.

Bu kalıbı bulduğumda, her zaman x Fromy işlevini adlandırıyorum .

Fonksiyonun yana dönüştüren bir belgeye bir Url, bunu seçeceğini

DocumentFromUrl

Bu model oldukça yaygındır. Örneğin:

atoi -> IntFromString
GetWindowWidth -> WidthInPixelsFromHwnd // or DxFromWnd if you like Hungarian
CreateProcess -> ProcessFromCommandLine

Bu UrlToDocumentsiparişten daha rahatsanız da kullanabilirsiniz . X Fromy veya y Tox demeniz büyük olasılıkla bir zevk meselesidir, ancak Fromsiparişi tercih ederim, çünkü bu şekilde işlev adının başlangıcı size hangi tür döndürdüğünü söyler.

Bir kongre seçin ve ona uyun. X Fromy işlevlerinizde sınıf adlarınızla aynı adları kullanmaya dikkat ediyorsanız , hangi adları kullandığınızı hatırlamak çok daha kolay olacaktır. Tabii ki, bu desen her şey için işe yaramaz, ancak "işlevsel" olarak düşünülebilecek kod yazdığınız yerde çalışır.

Bazen bir sınıf veya yöntem için iyi bir isim yoktur, hepimize olur. Bununla birlikte, çoğu zaman, bir isim bulamamanız, tasarımınızla ilgili yanlış bir şey için bir ipucu olabilir. Yöntemin çok fazla sorumluluğu var mı? Sınıfınız tutarlı bir fikir içeriyor mu?

Konu 1:

function programming_job(){
    while (i make classes){
         Give each class a name quickly; always fairly long and descriptive.
         Implement and test each class to see what they really are. 
         while (not satisfied){
            Re-visit each class and make small adjustments 
         }
    }
}

Konu 2:

while(true){
      if (any code smells bad){
           rework, rename until at least somewhat better
      }
}

Burada hiçbir yerde Thread.sleep (...) yok.

Programlama sırasında isim verilebilecek her şeyin isimleri hakkında endişelenmenin yanı sıra çok zaman harcıyorum. Gerçi çok iyi ödüyor diyebilirim. Bazen takıldığımda bir süre bırakıyorum ve bir kahve molası sırasında birinin iyi bir öneri olup olmadığını soruyorum.

Sınıfınız için öneririm VendorHelpDocRequester.

Steve Mcconnell tarafından Tamamlandı kitabının değişkenleri / sınıfları / fonksiyonları / ...

Bunun bir yan etkisi olduğunu düşünüyorum.

Zor olan gerçek adlandırma değil. Zor olan şey, isimlendirme sürecinin sizi ne yaptığınız hakkında hiçbir fikriniz olmadığı korkunç gerçeğiyle yüzleşmesidir.

Aslında bu teklifi dün, 37Signals'taki Signal vs. Noise blogu aracılığıyla duydum ve kesinlikle katılıyorum:

"Bilgisayar Bilimlerinde sadece iki zor şey vardır: önbellek geçersiz kılma ve şeyleri adlandırma." - Phil Karlton

Zor olması güzel. Sizi problemi ve sınıfın aslında ne yapması gerektiğini düşünmeye zorluyor. İyi isimler iyi tasarıma yol açabilir.

Kabul. Tip isimlerimi ve değişkenlerimi çok korkunç bir şekilde uzun olmadan mümkün olduğunca açıklayıcı tutmayı seviyorum, ancak bazen iyi bir kelime bulamadığınız belirli bir kavram var.

Bu durumda, her zaman bir iş arkadaşından girdi istememi yardımcı olur - sonuçta yardımcı olmasalar bile, genellikle en azından sesli olarak açıklamama ve tekerleklerimi döndürmeme yardımcı olur.

Geçen ay isimlendirme sözleşmeleri hakkında yazıyordum: http://caseysoftware.com/blog/useful-naming-conventions

Bunun özü:

verbAdjectiveNounStructure - isteğe bağlı parçalar olarak Yapı ve Sıfat ile

İçin fiiller , ben eylem fiiller sopa: bildirmek, silme, kaydetme, güncellemek veya üretir. Arada bir, "süreç" kullanıyorum ama sadece özellikle sıralara veya iş birikimine başvurmak için.

İçin isimler , bir sınıfını veya etkileşim olan nesne. Web2project'te bu genellikle Görevler veya Projelerdir. Javascript sayfa ile etkileşime giriyorsa, gövde veya tablo olabilir. Mesele, kodun etkileşimde olduğu nesneyi açıkça tanımlamasıdır.

Yapı o duruma özgü olduğu için isteğe bağlıdır. Bir liste ekranı Liste veya Dizi isteyebilir. Web2project için Proje Listesinde kullanılan temel işlevlerden biri getProjectList. Temeldeki verileri değiştirmez, sadece verilerin temsilini değiştirir.

Sıfatlar tamamen başka bir şey vardır. İsme değiştirici olarak kullanılırlar. GetOpenProjects kadar basit bir şey, bir getProjects ve switch parametresi ile kolayca uygulanabilir, ancak bu, temeldeki verilerin ve / veya nesnenin yapısının biraz anlaşılmasını gerektiren yöntemler üretme eğilimindedir ... teşvik etmek. Daha açık ve özel işlevlere sahip olarak, uygulamayı kullanarak kodu tamamen kapatabilir ve gizleyebilirsiniz. OO'nun noktalarından biri değil mi?

Bir sınıfı adlandırmaktan ziyade, uygun bir paket yapısı oluşturmak zor ama ödüllendirici bir zorluk olabilir. Modüllerinizin kaygılarını ve bunların uygulama vizyonu ile ilişkilerini ayırmayı düşünmelisiniz.

Uygulamanızın düzenini şimdi düşünün:

• Uygulama
  • VendorDocRequester (web hizmetinden okuyun ve veri sağlayın)
  • VendorDocViewer (satıcı belgelerini sağlamak için istekte bulunanı kullanın)

Birkaç dersin içinde çok şey olduğunu tahmin etmeye çalışıyordum. Bunu daha MVC ified yaklaşımına yeniden yansıtacak ve küçük sınıfların bireysel görevleri yerine getirmesine izin verecek olsaydınız, şöyle bir şeyle karşılaşabilirsiniz:

• Uygulama
  • VendorDocs
    • model
      • Belge (verileri tutan düz nesne)
      • WebServiceConsumer (web hizmetinde nitrit gritty ile ilgilenin)
    • kontrolör
      • DatabaseAdapter (ORM veya başka bir yöntem kullanarak kalıcılığı işleyin)
      • WebServiceAdapter (Bir Belgeyi almak ve veritabanına yapıştırmak için Tüketici'yi kullanın)
    • Görünüm
      • HelpViewer (belgeye tükürmek için DBAdapter kullanın)

Daha sonra sınıf adlarınız, tam bağlam sağlamak için ad alanına güvenir. Sınıfların kendileri, açıkça söylemeye gerek kalmadan, doğası gereği uygulama ile ilişkilendirilebilir. Sınıf isimleri daha basit ve sonuç olarak daha kolay tanımlanabilir!

Bir diğer çok önemli öneri: lütfen kendinize bir iyilik yapın ve Head First Design Patterns'in bir kopyasını alın. Uygulamanızı düzenlemenize ve daha iyi kod yazmanıza yardımcı olacak harika, kolay okunan bir kitap. Takdir edilen tasarım kalıpları, karşılaştığınız sorunların çoğunun zaten çözülmüş olduğunu anlamanıza yardımcı olacak ve çözümleri kodunuza dahil edebileceksiniz.

Leo Brodie, "Düşünme İleri" adlı kitabında, bir programcı için en zor görevin isimleri iyi adlandırdığını yazdı ve en önemli programlama aracının bir eş anlamlılar sözlüğü olduğunu belirtti.

Eşanlamlılar sözlüğünü http://thesaurus.reference.com/ adresinde kullanmayı deneyin .

Bunun ötesinde, HİÇ Macarca Notasyonu kullanmayın, kısaltmalardan kaçının ve tutarlı olun.

En iyi dileklerimle.

Kısacası:
İyi isimlerin önemli olduğunu kabul ediyorum, ama ne pahasına olursa olsun onları uygulamadan önce bulmanız gerektiğini sanmıyorum.

Tabii en başından beri iyi bir isme sahip olmak daha iyidir. Ancak 2 dakikada bir tane bulamazsanız, daha sonra yeniden adlandırmak daha az zaman alır ve üretkenlik açısından doğru seçimdir.

Uzun:
Genellikle uygulamadan önce bir isim hakkında çok uzun düşünmeye değmez. Sınıfınızı uygularsanız, "Foo" veya "Dsnfdkgx" olarak adlandırırken, uygularken onu adlandırmanız gereken şeyi görürsünüz.

Özellikle Java + Eclipse ile, tüm sınıflardaki tüm referansları dikkatli bir şekilde ele aldığı, sizi isim çarpışmalarına vb. 5 kez yeniden adlandırmada yanlış bir şey olduğunu düşünmeyin.

Temel olarak, bu yeniden düzenleme hakkında nasıl düşündüğünüzün bir sorusu. Şahsen, hoşuma gidiyor, ancak takım arkadaşlarını bazen rahatsız ediyor, ancak asla çalışan bir sisteme dokunmadığına inanıyorlar . Ve yeniden düzenleyebileceğiniz her şeyden, isimleri değiştirmek yapabileceğiniz en zararsız şeylerden biridir.

Neden HelpDocumentServiceClient tür bir ağız dolusu veya HelpDocumentClient ... bir satıcı olduğu önemli değil, bu nokta, yardım belgeleriyle ilgilenen bir web hizmetinin müşterisi olmasıdır.

Ve evet isimlendirme zor.

Bu sınıf için sadece bir mantıklı isim var:

HelpRequest

Uygulama ayrıntılarının sizi anlamdan uzaklaştırmasına izin vermeyin.

İyi bir yeniden düzenleme aracına yatırım yapın!

Temel bilgilere bağlı kaldım: VerbNoun (argümanlar). Örnekler: GetDoc (docID).

Süslü olmaya gerek yok. İster bir yıl, ister bir başkası olsun, bir yılı anlamanız kolay olacak.

Benim için bir yöntemin veya sınıf adının açıklayıcı ve doğru kitaplıkta ne kadar uzun olduğu umurumda değil. Uzun zamandır, API'nın her bölümünün nerede olduğunu hatırlamanız gereken günler.

Intelisense tüm ana diller için mevcuttur. Bu nedenle, üçüncü taraf bir API kullanırken, 'gerçek' dokümanları kullanmak yerine, onun bilgisini dokümantasyon için kullanmayı seviyorum.

Bunu göz önünde bulundurarak,

StevesPostOnMethodNamesBeingLongOrShort

Uzun - ama ne olmuş. Kim bu gün 24 inç ekranlar kullanmaz!

İsimlendirmenin bir sanat olduğu konusunda hemfikirim. Sınıfınız belirli bir "desigh desenini" (fabrika vb.) Takip ediyorsa biraz daha kolaylaşır.

Bu, bir kodlama standardına sahip olmanın nedenlerinden biridir. Standart olması gerektiğinde isimleri bulmaya yardımcı olma eğilimindedir. Diğer daha ilginç şeyler için kullanmak için zihninizi özgürleştirir! (-:

Steve McConnell'in Kod Tamamlama'nın ( Amazon bağlantısı ) okunabilirliğini ve hatta sürdürülebilirliğini sağlamak için çeşitli kurallara giren ilgili bölümünü okumanızı tavsiye ederim .

HTH

şerefe,

soymak

Hayır, hata ayıklama benim için en zor şey! :-)

DocumentFetcher? Bağlam olmadan söylemek zor.

Bir matematikçi gibi davranmanıza ve alanınız için bir sözlük oluşturmanıza / bulmanıza yardımcı olabilir: konsepti her seferinde hecelemeden öneren kısa düz kelimelere yerleşin. Çok sık seni kısaltmalar için bir sözlük ihtiyaç yapım kısaltmalar dönüştü uzun Latin kökenli ifadeler bakın zaten .

Sorunu tanımlamak için kullandığınız dil, değişkenler, yöntemler, nesneler, sınıflar, vb. İçin kullanmanız gereken dildir. Sorunu tanımlamak için kelimeler eksikse, sorunun tam olarak anlaşılmasını (spesifikasyonunu) da kaçırıyorsunuz.

Sadece bir ad kümesi arasında seçim yapılıyorsa, sistemi oluşturmak için kullandığınız kurallar tarafından yönlendirilmelidir. Önceki sözleşmelerle ortaya çıkarılan yeni bir noktaya geldiyseniz, bu yeni vakayı kapsayacak şekilde (düzgün, tutarlı bir şekilde) genişletmeye çalışmak için her zaman biraz çaba sarf etmeye değer.

Şüpheniz varsa, üzerinde uyuyun ve ertesi sabah ilk en belirgin ismi seçin :-)

Bir gün uyanır ve yanıldığınızı fark ederseniz, hemen değiştirin.

Paul.

BTW: Document.fetch () oldukça açık.

Yerel değişkenlerde en fazla sorun yaşadığımı görüyorum. Örneğin, DocGetter türünde bir nesne oluşturmak istiyorum. Bu yüzden bir DocGetter olduğunu biliyorum. Neden başka bir isim vermem gerekiyor? Genellikle dg (DocGetter için) veya temp ya da eşit derecede açıklayıcı olmayan bir şey gibi bir isim vererek sona erer.

Unutmayın tasarım desenleri (sadece GoF olanlar değil) ortak bir kelime dağarcığı sağlamanın iyi bir yoludur ve isimleri duruma uygun olduğunda kullanılmalıdır. Bu, isimlendirmeye aşina olan yeni gelenlerin mimariyi hızlı bir şekilde anlamalarına bile yardımcı olacaktır. Üzerinde çalıştığınız bu sınıfın bir Proxy, hatta bir Cephe gibi davranması gerekiyor mu?

Nesne satıcı belgeleri olmamalı mı? Yani, bu programın bir kısmının antropomorfizasyonu kadar değil, elle tutulur. Yani, VendorDocumentationbilgileri getiren bir kurucuya sahip bir sınıfınız olabilir . Bir sınıf adı bir fiil içeriyorsa, genellikle bir şeyler yanlış gitti.

Seni kesinlikle hissediyorum. Ve acını hissediyorum. Düşündüğüm her isim bana saçma geliyor. Her şey çok genel görünüyor ve sonunda isimlerime biraz yetenek ve yaratıcılık nasıl enjekte edileceğini öğrenmek istiyorum, bu da onları tarif ettiklerini gerçekten yansıtıyor.

Bir önerim bir Eş Anlamlılar Sözlüğü ile görüşmektir. Mac OS X'de olduğu gibi Word'ün de iyi bir yanı var. Bu gerçekten başımı bulutlardan çıkarmama yardımcı olabilir ve bana iyi bir başlangıç ​​yeri ve biraz ilham verir.

Ad kendini bir programcıya açıklarsa, muhtemelen onu değiştirmeye gerek yoktur.