Türünden yalnızca duruma göre farklılık gösteren bir değişken adı kullandığım için ahlaksız mıyım?

Örneğin, şu kod parçasını alın:

var person = new Person();

veya sizin için Pythonistalar:

person = Person()

Bana sürekli bunun ne kadar kötü olduğu söylendi, ancak henüz bu iki kod satırının ahlaksızlığına dair bir örnek görmedim. Benim için kişi bir Kişidir ve ona başka bir isim vermeye çalışmak zaman kaybıdır. Sanırım sözdizimi vurgulamadan önceki günlerde, bu çok önemli olurdu. Ancak bu günlerde, değişken adından ayrı bir tür adı söylemek oldukça kolaydır. Heck, farkı burada SO'da görmek bile çok kolay.

Yoksa kaçırdığım bir şey mi var? Öyleyse, sorunlara neden olan bir kod örneği vermeniz yararlı olacaktır.

Bunun kötü olduğunu söyleyenlerin mantığı nedir? Bunu her zaman yaparım. Bir türdeki tek bir değişkeni adlandırmanın en basit ve anlamlı yoludur. İki Personnesneye ihtiyacınız varsa, o zaman aşağıdaki persongibi anlamlı sıfatların önüne ekleyebilirsiniz.

fastPerson
slowPerson

aksi halde sadece

person

benim için sorun değil.

Bu kalıbı yöntem imzalarında çok kullanıyorum. Alternatif bir açıklayıcı ad ve ardından IMHO sağlayamıyorsam, bunda yanlış bir şey yok.

Yanlış olan, iki tip Kişi ve kişiniz varsa, o zaman bu çok çok yanlıştır.

Geçici nesne referansları için her zaman kullanıyorum. İlkel veri türleri için veba gibi bundan kaçınırdım.

Person person = new Person(); // okay

int Int = 42; // pure evil

Birisi bunun kötü olduğunu söylüyorsa, bunun daha iyi olup olmadığını sorun:

var abc = new Person();

Kişi bağlamda genel bir Kişi ise, o zaman "kişi" gerçekten iyi bir isimdir. Tabii ki, Kişinin kodda belirli bir rolü varsa, o rolü kullanarak ona isim vermek daha iyidir.

Sanırım böyle söylediğim için olumsuz oy vereceğim, ama ...

Destansı bir cinayete ve açgözlülüğe tanıklık ederek henüz yüzyılı geçtikten sonra, yapabileceğimiz en ahlaksız şey bir değişken isimlendirmekse, biz programcılar gerçekten kutsanmış durumdayız.

Bunun ille de "kötü" olduğunu sanmıyorum, ama açıkçası, onu nasıl bir kişi olduğu gibi daha fazla bağlam sunmaya hak kazanırsanız (muhtemelen birçok olası kişiden yalnızca biriyle uğraşıyorsunuz), o zaman başka biri onu seçiyor yukarı daha iyi anlayabilir.

Jason - Bunun kötü olduğunu sana kimin söylediğinden emin değilim. Birkaç yazar bunu bir Sınıfın Örneğini (küçük harf) (büyük harfle yazılmış) ifade etmenin standart bir yolu olarak kullanır .

Bunu oldukça sık kullanıyorum çünkü alt harfli değişkenin aslında bana sadece bunun bir örnek olduğunu değil aynı zamanda sınıfın adını da ilettiğini görüyorum.

Birinin aksine sağlam bir argüman olmadıkça, kesinlikle bunu yapmaya devam edeceğim.

Kötü sayılmasının nedeni, ileride 2 Kişiye sahip olmanız gerekiyorsa, daha sonra buna benzeyen bir kod elde edebilirsiniz.

Kişi kişi = yeni Kişi ();

Kişi person2 = yeni Kişi ();

Bu, daha sonra "Kötü" sınırında olacaktır. Ancak bu durumda, ikisini birbirinden ayırt etmek için asıl kişinizi yeniden düzenlemelisiniz.

Örneğinize gelince, "kişi" değişken adı, "Kişi" nesnesi için mükemmel bir tanımlayıcı addır. Bu nedenle bunda yanlış bir şey yok.

Ne olduğunu söylüyorum: Değişken 2 köpeği olan bir kişiyi temsil ediyorsa, onu arayın personWith2Dogs. Değişkenin kısa kapsamı vardır (bir döngü var gibi) o zaman kişi iyidir.

Bunu kodumda çok kullanıyorum ve bunda yanlış bir şey olduğunu düşünmüyorum. Bununla birlikte, ben (muhtemelen) onu bir ekrandan daha uzun bir yöntemde kullanmam ve birden fazla Kişi sınıfı örneği varsa kullanmam. Kesinlikle onlara person1, person2, person3 adını vermeyin ... bunun yerine person_to_del, person_to_ban, person_to_update vb. Gibi daha açıklayıcı bir şey kullanın.

Ahlaksız değil, ancak genel bir arama her ikisini de bulacaktır Personve personbüyük / küçük harf duyarlılığını etkinleştiremezseniz. Genel aramayı / değiştirmeyi kolaylaştırmak için bir önek tercih ederim, ancak kesinlikle Macarca veya uzun / karmaşık bir şey DEĞİL. Yani, kullanıyorum ...

Personbir sınıf değişkeni için bir örnek değişkeni için bir yöntem parametresi için bir aPersonyerel değişken thePersoniçin sınıf / tür için myPersonourPerson

Nadir durumlarda, pLOTS referansımın olduğu yerel bir bağlamda kullanabilirim , ancak bu genellikle yalnızca döngü dizinleri ve benzerleri için geçerlidir.

Değişir.

Sıkı bir büyük harf kullanım stiliniz varsa, değişkenler küçük harfle başlarsa (ve sözcük sonları için alt çizgi veya camelCase kullanılırsa) ve Sınıflar Büyük Harflerle başlarsa, kişinin bir değişken ve Kişinin bir sınıf olduğu ve birisi bunu anladığında , örtüşen ad alanlarında görünmeyecekler. (Benzer şekilde, insanlar fiil veya isim "lehçe" ile "Lehçe" sıfatı arasında neredeyse hiç kafa karıştırmaz.)

Eğer böyle bir tarzınız yoksa, o zaman kolayca karıştırılabilecek ve sadece duruma göre farklılık gösteren iki adınız vardır. Bu kötü.

Bu insanların kullandığı kesin argümanlar nelerdir?

Kişiyi değişken adı olarak kullanmanıza izin vermiyorlarsa, 'a' önekini eklemeyi düşünebilirsiniz.

aPerson = Person()

Yaptığın şeyin iyi olduğunu düşünüyorum. Genel olarak, kodlama standartlarını kabul etmenin önemli olduğunu düşünüyorum.

Örneğin örnekler, değişkenler için lowerCamelCase ve sınıflar için UpperCamelCase kullanıyorum.

Kodlama standartları bu sorunu ortadan kaldırmalıdır.

Başarılı açık kaynaklı programlara baktığımda genellikle kodlama standartları vardır

http://drupal.org/coding-standards

http://help.joomla.org/content/view/826/125/

http://wiki.rubyonrails.org/rails/pages/CodingStandards

http://lxr.linux.no/linux/Documentation/CodingStyle

Kodlama standartlarını kabul etmek, bu konudaki son savaşınız olmalıdır.

Aslında wikipedia girişine bakın ( http://en.wikipedia.org/wiki/CamelCase adresinden )

Programlama ve kodlama stili

Dahili büyük harf kullanımı bazen kaynak kodu yazmak için kodlama stili yönergelerine göre kelime sınırlarını belirtmek için önerilir (örneğin, Mesa programlama dili ve Java programlama dili). Bu kılavuzlardan bazılarında yer alan öneriler, kaynak koduna uyumu kontrol eden statik analiz araçlarıyla desteklenmektedir.

Bu öneriler genellikle UpperCamelCase ve lowerCamelCase arasında ayrım yapar ve tipik olarak belirli varlık türleri için hangi çeşidin kullanılması gerektiğini belirtir: değişkenler, kayıt alanları, yöntemler, prosedürler, tipler, vb.

Yaygın olarak kullanılan bir Java kodlama stili, UpperCamelCase'in sınıflar için kullanılmasını ve lowerCamelCase'in örnekler ve yöntemler için kullanılmasını gerektirir. [19] Bu kullanımın farkında olan Eclipse gibi bazı IDE'ler, CamelCase'e dayalı kısayollar uygular. Örneğin, Eclipse'in İçerik yardımı özelliğinde, bir CamelCase kelimesinin yalnızca büyük harflerinin yazılması, eşleşen herhangi bir sınıf veya yöntem adını önerecektir (örneğin, "NPE" yazmak ve içerik yardımını etkinleştirmek "NullPointerException" anlamına gelebilir).

Orijinal Macarca programlama notasyonu, "kullanım türü" (veri türü değil) için küçük harfli bir kısaltmanın tüm değişken adlarının önüne geçmesi gerektiğini belirtir; adın geri kalanı UpperCamelCase'de; bu nedenle bir LowerCamelCase biçimidir. CamelCase, Java'daki dosya adları ve Amiga kişisel bilgisayarı için resmi bir sözleşmedir.

Microsoft .NET, parametreler ve genel olmayan alanlar için lowerCamelCase'i ve diğer tanımlayıcı türleri için UpperCamelCase'i ("Pascal Stili" olarak da bilinir) önerir. [20]

Python, sınıf adları için UpperCamelCase önerir. [21]

NIEM kayıt defteri, XML Data Elements'in UpperCamelCase, XML Attributes ise lowerCamelCase kullanmasını gerektirir.

Büyük harfli kısaltmaların (esas olarak kısaltmalar ve baş harflerle) CamelCase adlarına dahil edilmesi için tek bir kural yoktur. Yaklaşımlar, tüm kısaltmanın büyük harfle bırakılmasını ("useHTTPConnection" gibi) ve yalnızca ilk harfi büyük harf olarak bırakmayı ("useHttpConnection" gibi) içerir.

Deve vakası, bilgi işlemde hiçbir şekilde evrensel değildir. Birkaç modern programlama dilinin kullanıcıları, özellikle Lisp ve Forth ailelerindekiler, neredeyse her zaman kısa çizgi kullanır. Bazen verilen nedenler arasında, bunu yapmanın çoğu klavyede kaydırmayı gerektirmemesi, sözcüklerin ayrıldıklarında daha okunabilir olması ve büyük / küçük harfe duyarlı olmayan veya büyük / küçük harf katlama dillerinde (örn. Teknik olarak büyük / küçük harfe duyarlı bir dil olan Common Lisp, tanımlayıcıları varsayılan olarak büyük harfe standartlaştırır (katlar).

Bu türden yöntem adlarının yalnızca zararsız olmakla kalmayıp, aynı zamanda iyi kalitede kodun bir göstergesi olabileceği konusunda daha güçlü bir argüman yapmak mümkündür.

• İyi kod ayrıntı düzeyinin bir göstergesi: Yöntemleriniz kısa, tek amaçlı ve açıklayıcı bir şekilde adlandırılmışsa, değişken adlarında çok fazla bilgiye ihtiyacınız yoktur. Çok şey yapan uzun yöntemleriniz varsa ve birçok bağlamı ve durumu takip etmeniz gerekiyorsa, değişken adlarınızın daha açıklayıcı olması gerekir.

• Genel amaçlı hesaplamaların genel amaçlı yöntemlere itildiğinin bir göstergesi: Bir iş yönteminde veri yapılarının orta düzeyde bir manipülasyonunu yaparsanız, örneğin bir dizi kullanıcının tekilleştirilmesi gerekir, kapsamda değişkenlere sahip olmanız gerekir. isimler gibi olan users[]ve deduplicatedUsers[]. Tekilleştirmeyi bir yardımcı program yöntemine taşırsanız, yöntemi Utils.dedup(array)çağırabilir ve tekilleştirilmiş diziyi deduplicatedArrayveya sadece result.

• Java kod çözücüler genellikle yerel değişkenleri adlandırmak için böyle bir şema kullanır (örnek ve sınıf değişkenleri normalde bayt kodunda bulunur, ancak yerel değişkenler değildir) ve sonuçlar beklediğinizden daha okunabilir, aslında genellikle orjinal kaynak.

• Larry Wall'un "Yerel Belirsizlik Tamam" ilkesine bakın - http://www.wall.org/~larry/natural.html .

Bir nesne yarattığınızda muhtemelen aklınızda belirli bir kullanım olduğunu söyleyebilirim. Tip tek başına çok nadiren bu kullanımı yansıtır.

Bu nedenle, adres defteri uygulamanızda yeni bir kişi oluşturmak istiyorsanız, değişkeni aramak isteyebilirsiniz newContact.

Ve eğer kodunuzu isimsiz Personnesnelerin davranışını kontrol etmek için birim test ediyorsanız , onları çağırmak unnamedPersonveya benzer bir şey isteyebilirsiniz .

Bunu adlandırmak person, kodunuzun kendi kendini belgelendirmesi için büyük bir şansı ortadan kaldırır.

Yalnızca VB6'da programlama yapıyorsanız. Bu durumda yaptığınız şey yasa dışıdır, ancak ahlak dışı değildir.

Ben de yapıyorum ve neden 'ahlaksız' olması gerektiğini de anlamıyorum. Bazen kafa karıştırıcı olabileceğini anlayabilsem de, bugün Intellisense ve sözdizimi vurgulamalı IDE'lere sahibiz (bir hata yaparsanız ve sınıfınız yerine değişkeninize referans verirseniz ve bunun tersi de geçerlidir) Hatanızı oldukça hızlı görün. Ayrıca derleyiciye sahibiz. :)

Ayrıca bu uygulamada herhangi bir sorun görmüyorum. Bu sınıfın sadece bir değişkeni olduğu sürece, yazması ve okuması kolaydır. Imo, bu temel bir metin düzenleyicide bile geçerlidir. Şahsen kimsenin bu kadar kötü, hatta ahlaksız dediğini hatırlayamıyorum. Bunu yapmaya devam et :)

Sanırım düşündüğünüz 'kural' daha çok ilkel tipler ve sınıf adının zayıf bir değişken adı yaptığı sınıflar için tasarlandı.

Örneğin, bir çevrimiçi mağazadaki belirli bir öğenin maliyetini hesaplamakla uğraşıyorsanız, aşağıdaki kod iyi bir biçimde olmaz:

Decimal _decimal = item.BaseCost + item.Tax;

Bunun yerine, "_total" veya "_cost" gibi daha açıklayıcı bir ad önerilir.

Bu tür şeylerle ilgili bulduğum tek sorun, özel bir üye ve aynı zamanda bir kamu malı için aynı adı isteyip istemediğinizdir.

Bunlar yalnızca büyük / küçük harfe göre farklılık gösteriyorsa, C # gibi büyük / küçük harfe duyarlı dillerde sorunsuz çalışır, ancak VB.NET'te çalışmaz.

Yani, örneğin VB'de yazarım

Private _name As String

fakat

Public Property Name() As String
    Get
        Return _name
    End Get
    Set(ByVal Value As String)
        _name = Value
    End Set
End Property

C # için de aynısını yapardım, böylece birinden diğerine çeviri ağrısız olur. Ayrıca, yanlış okunması çok kolay olduğu veya yalnızca duruma göre farklılık gösteren yanlış yazılan sözcükler olduğu için onu biraz daha az hataya yatkın hale getirir.

Ahlaksız değil, ancak değişkeniniz için en iyi adınız türün adıysa, yanlış bir şey veya sadece kavramın bir kanıtı veya bunun gibi bir şey yapıyorsunuz. Benim için bir değişken adı, programlama diline değil, iş bağlamındaki anlamı ifade etmelidir. Kodu anlamak daha zor olacaktır.

Sık sık Person person = new Person()kendimi kullanırım . Java / C # 'da yaygın olarak kullanılır.

Dün neden diye merak etmeme rağmen

private enum DataType {NEW, OLD}

C # ile çalışmıyor ...

Özellikle nasıl kullanabileceğinizi görerek String, string, Double, double, ... C # irade.

Person person = new Person()

benim kitabımda iyi.

Korkunç hale gelen şey, sahip olduğunuz zamandır:

string Person;
string person;

2'yi karıştırmak çok kolay.

Kodlama Standartlarımıza uymamak dışında bana ifade edilen şey, başka biri kodumu okurken kafa karışıklığı yaratmaktan kaçınmaktır. Ben şahsen, anlamı açık olduğu sürece bununla ilgili bir sorun görmüyorum.

CLR türlerine (int, string, vb.) Gelince, türü bildirmek için String ya da string (vb.) Kullanabilirsiniz, bu yüzden böyle bir şey kullanmaktan kaçınırım

int Int = 0;
string String = "hi there";

Büyük harf kullanımını tek fark yapmak tehlikelidir ... bunu büyük bir proje için yapmaya devam edin ve bulamayacağınız tuhaf hatalarla karşılaşacağınızı garanti ederim.

fastPerson / slowPerson yukarıdaki gibi iyidir ... tanımlayıcıdırlar ve değişken türü adından farklıdırlar ... ama hadi adamım, int "Int" olarak adlandırmak tamamen tembellik olur.

Hiçbir zaman ahlaka aykırı olmadığını söyleyebilirim - gerçekten sadece temel değişken adınız. Daha iyi bir ad düşünemiyorsanız, adını türüne göre adlandırmak iyi bir varsayılandır. ( Yalnızca karmaşık türler için - yerleşik türler için kötüdür ) Ve çoğu zaman daha iyi bir ad yoktur çünkü değişken hakkında başka hiçbir şey bilmiyorum. Bu yöntemde olduğu gibi

void SaveToDatabase(Person person) {...}

Makul olarak kişiyi arayabileceğiniz diğer tek şey person_to_saveya da gereksiz görünen buna benzer bir şeydir.

Bununla birlikte, çoğu durumda, kişiyi daha açıklayıcı bir adla değiştirerek kodunuzun okunabilirliğini artırabilirsiniz. Örneğin, bu daha az açıklayıcıdır

void AddToAccount(Account account, Person person)  {...}

Bundan daha

void AddToAccount(Account account, Person dependent)  {...}

Ancak lütfen, lütfen - lütfen tür adının önüne "a" veya "t" koymayın. IE 'bir kişi' için bir Kişi veya 'kişi' için bir Kişi. Aşırı karmaşıktır ve herhangi bir değer varsa fazla bir şey katmaz. Artı, a veya t ile başlayan ve intelli-sense'in değerini en aza indirebilecek bir dizi değişkenle kapsamınızı kirletmeye başlarsınız.

Korkunç olduğunu söyleyemem. Tipin tek bir örneği olduğunu göstermek için bu tür bir şeyde genellikle değişkenin adını 'a' ile ön ekliyorum, bu yüzden yapardım

Person aPerson = new Person();

Bence kodun daha doğal okunmasını sağlıyor.

Başkaları tarafından belirtilen uyarılara tabi olarak kesinlikle yanlış bir şey yok (burada kolaylık sağlamak için özetleniyor): ilkel türlerle yapmamak, daha sonra başka bir örnek eklenirse orijinal örneği yeniden düzenlemek, sınıf adlarını farklılaştırmak için char-case kullanmamak, vb.

Temel kuralım mı? Koddaki ifadeler basit İngilizce cümleler gibi okunmalıdır.

Kişi kişi = yeni Kişi ();

Çalışan çalışan = person.getRole (EMPLOYEE);

Ebeveyn ebeveyn = person.getRole (PARENT);

person.getFullName ();

staff.getSalary ();

parent.getChildren ();

parent.getFullName (); // oyunda dekoratör kalıbı varsayarsak

if (person.hasRole (EMPLOYEE)) {

  ...

}

Ve benzeri.

Değişkenin kapsamı sınırlıysa (örneğin, kapsülleme yöntemi 10-15 satırdır) 'kişi' yerine 'p' bile kullanabilirim. Daha kısa değişken isimleri, bağlamı kafanızda tutmaya çalışırken daha az dikkat dağıtıcıdır. 'A' veya (titreyen) Macar notasyonu ve bunların dalları gibi gereksiz öneklerden kaçının. (Unutmayın, uygun bağlamda kullanıldığında bu tür öneklere karşı hiçbir şeyim yok - C ++ / COM / ATL / Win32 API kodu vs., burada atamaları / yazımları düz tutmaya yardımcı olur).

İki (!) Bitim :-)