Adlandırma kuralları: camelCase vs. underscore_case? bu konudaki düşünceleriniz neler? [kapalı]

2 yıldan beri undercore_case kullanıyorum ve yakın zamanda yeni iş nedeniyle camelCase'e geçtim (sonrakini yaklaşık 2 aydır kullanıyordum ve yine de undercore_case'in dahil olan birçok programcının bulunduğu büyük projeler için daha uygun olduğunu düşünüyorum.) temelde kodun okunması daha kolay olduğu için).

Artık işteki herkes camelCase kullanıyor çünkü kod diyor ki daha şık görünüyor.

CamelCase veya underscore_case hakkındaki düşüncelerin neler?

ps lütfen benim kötü ingilizce pardon

Düzenle

Önce bazı güncellemeler:

• Kullanılan platform PHP'dir (ama PHP platformuyla ilgili katı cevaplar beklemiyorum, herkes en iyi kullanımı için düşüncelerini paylaşabilir, bu yüzden ilk başta buraya geldim)

• CamelCase'i tıpkı ekipteki diğer herkes gibi kullanıyorum (çoğunuzun önerdiği gibi)

• camelCase'i de öneren Zend Framework kullanıyoruz

Bazı örnekler (PHP ile ilgili):

• Codeigniter çerçevesi, undercore_case'i önerir ve dürüst olmak gerekirse, kodun okunması daha kolaydır.

• ZF, camelCase'i önerir ve ZF kodunu takip etmenin biraz zor olduğunu düşünen tek kişi ben değilim.

Yani benim sorum tekrar ifade edildi:

Adlandırma kurallarını tavsiye etmeyen ve Foo'nun seçim yapması gereken bir platform olan Foo platformuna sahip olduğunuzu düşünelim. Sen o takım liderisin, neden camelCase'i seçtin ya da neden underscore_case?

ps şimdiye kadar hızlı cevaplar için herkese teşekkürler

Bir dereceye kadar kullandığınız dile bağlı olduğunu kabul ediyorum; Kodunuz, sembol isimleriniz dilin yapıları ve stok kütüphaneleriyle aynı formatı takip ettiğinde daha düzenli görünmeye meyillidir.

Ancak bir seçimin olduğu yerde, basit bir nedenden ötürü deve davasının altını çizmeyi tercih ediyorum: Bu stili okumayı daha kolay buluyorum. İşte bir örnek: Hangisini daha okunaklı buluyorsun? Bu:

aRatherLongSymbolName

veya bu:

a_rather_long_symbol_name

Alt çizgi sürümünü okumak daha kolay buluyorum. Beynim o sınırları zıt davanın diğer gliflere benzer gliflerine veya sayı arasında (özellikle nerede, deve durumda Büyük / küçük sınırlarını algılayabilir çok daha kolay alt çizgi yok sayabilirsiniz I/l, O/0, t/I, vs). Örneğin, bu boolean değişkeni, bir Igloo'nun uygun planlama izniyle inşa edilip edilmediğini belirten bir değeri saklar (şüphesiz hepimiz için ortak bir kullanım durumu):

isIllicitIgloo

Bu sürümü okuması çok daha kolay buluyorum :

is_illicit_igloo

Belki de okunması zor bir sembol adından bile daha kötüsü yanlış okunması kolay bir sembol adıdır. İyi sembol isimleri kendiliğinden belgelenir, bu da benim için onları bir bakışta okumanız ve anlamlarını anlamanız gerektiği anlamına gelir. (Eminim hepimiz yatakta kod çıktısını zevk almak için okuduğumuza eminim, ama bazen acele çekiyoruz.) Sık sık deve sembolü sembol isimleriyle onları yanlış okumayı ve yanlış bir izlenim elde etmeyi kolay buluyorum. sembolün anlambilimi.

Platformunuz tarafından kabul edilen adlandırma kurallarını kullanmanız gerektiğini düşünüyorum. underscore_case C # kodunda tuhaf görünecek, Ruby'de camelCase =)

Dürüst olmak gerekirse, takımdaki herkes aynı programı kullandığı sürece farketmez. Şanslar bir veya diğeri sizin için daha doğal olsa da, asıl önem, uzun vadede kodun okunabilirliğidir ve daha sonra herkesin aynı adlandırma kurallarına uyması çok önemlidir.

John Isaacks'in cevabına göre:

"dürüst olmak gerekirse kodu okumak daha kolay" Görüş ya da gerçek?

Biraz araştırma yapmaya karar verdim ve bu yazıyı buldum . Bilim bu konuda ne söyleyecek?

1. Deve kasası, alt çizgilerden daha büyük bir doğruluk olasılığına sahiptir . (oranlar% 51,5 daha yüksek)
2. Ortalama olarak, deve vakası % 13,5 daha uzun olan 0,42 saniye sürdü .
3. Eğitimin, stilin doğruluğu nasıl etkilediği üzerinde istatistiksel olarak anlamlı bir etkisi yoktur.
4. Daha fazla eğitim görenler deve davası tarzındaki tanımlayıcılar üzerinde daha hızlı davrandılar .
5. Bir stildeki antrenman, diğer stildeki bulma süresini olumsuz yönde etkiler .

Konuyla ilgili blog yazımda , bilimsel makaleyi inceliyorum ve aşağıdaki sonucu çıkardım.

Sadece deve kasasının yavaşlığı (2) programlama ile gerçekten ilgilidir, diğer ID'ler modern IDE'ler ve araştırmadaki camelCase kullanıcılarının çoğunluğu nedeniyle ilgisiz olduğu için reddetmektedir. Tartışma (anket ile birlikte) blog yazısında bulunabilir.

Bu makalenin fikirlerini nasıl değiştirebileceğini merak ediyorum. :)

En Zeki Çocukları Kopyala

Programlama dilleri durumunda, dilin geliştiricisinin stilini kopyalayın.

Örneğin, K&R'de yapıldığı gibi C kodunu tam olarak yazdım.

Sonra, herhangi biri sıkıcı bir kodlama tarzı sohbete başlamaya çalıştığında, onlara "Dennis Ritche'le bunu getirmelerini ve ne söylediğini bildirmelerini" söyleyebilirim.

Genel olarak camelCase'i tercih ederim. Ancak bunun nedeni kariyerimin çoğunun, stil kılavuzlarının normalde camelCase'i önerdiği diller ve ortamlarda çalışıyorum. (Java, ECMAScript, C ++). Siz, bir PHP insanı olmanızın tersini tercih etmeniz olasıdır.

Bununla birlikte, üçOrFourWords'ün ötesine geçtiğinizde ya da XmlForExample gibi ilkleri kullanıyorsanız, okunabilirliği durduğunu söyledi.

Bu yüzden emacs bize gözlük kipi veriyor.

camelCase

Bu, her zaman okunabilirlik üzerine 'tür kabiliyeti' seçeceğim yerlerden biri. CamelCase'in yazılması daha kolay ve parmaklarıma daha nazik davranmak benim için hafif bir okunabilirlik kazancı kazanıyor.

Elbette, projenin farklı bir standartta mevcut bir kod temeli üzerine inşa etmediği varsayılmaktadır.

Bu ilginç bir soru, bunu defalarca düşündüm. Ama kesin bir cevap yok sanırım.

"Kültürel" sözleşmelerin ardından iyi bir seçimdir. Bu durumda “kültürel” ekip / şirkette kurulan sözleşmeler anlamına gelir ve temel olarak dil / platform sözleşmelerini de taşırlar. Başkalarının kodunuzu kolayca okumasına / kullanmasına yardımcı olur ve kodunuzu anlama yolunda ek çaba ve zaman gerektirmez.

Bazen kabul edilen gösterimleri kırmak ilginçtir. Küçük projelerimden biri (Python'da) underscored_namesfaydalı işlevler / "korumalı" yöntemler ve Java tarzı methodNamesyöntemler için kullandım. Ekibim onunla mutlu oldu :)

Programlama diline göre değişir.

Macar gösterimini kullanıp kullanmama konusunda aynı teknede kullanmayı düşünüyorum:

• Python: underscore_case, Macarca notasyonu yok
• C ++: camelCase, Macarca notasyonu

Her ikisi de!

Ben CakePHP'de gelişme çok şey ve ben de kullanabilir CamelCaseveya $underscored_varsaşağıdaki moda (hatta CakePHP'nin Projeleri dışında) içinde,:

1. dosya adları - /lowercased_underscored.phpTipik, ancak bahsedilmeye değer.
2. sınıflar - class CamelCase extends ParentObject. Kullanırken CamelCase, ilk karakterin küçük harf olmadığını unutmayın. Ben bulmak camelCasebakmak gerçekten garip.
3. değişkenler -$are_variables_underscored === TRUE;
4. örnekleri tutan değişkenler -$CamelCase = new CamelCase();
5. dizi tuşları -$collection['underscored_keys'];
6. Sabitler - Bence herkes sabitlerin olması gerektiği konusunda hemfikir olabilir ALL_CAPS_AND_UNDERSCORED.
7. yöntemler -$CamelCase->foo_method_underscored();
8. statik yöntemler -CamelCase::just_like_regular_methods();

Kişisel olarak tercih ediyorum underscore_caseçünkü daha okunaklı buluyorum, ancak mevcut kod temeli ile tutarlılığın çok daha önemli olduğunu belirten diğer cevaplayıcılarla aynı fikirdeyim.

Ancak, "dilinizin ve kütüphanelerinin kurallarına uyun" diyenlere karşı bir örnek var.

Geçmişte Windows kullanarak C kodunu yazdık underscore_caseve PascalCaseWin32 işlevlerini çağırdık :

if (one_of_our_conditions_is_true())
{
    call_one_of_our_functions();
    CallSystemFunction();
}

İşlev isimlerimizle Microsoft'un işlev isimleri arasındaki görsel ayrım, kodun "sistem ülkesi" ne zaman girdiğini açıkça gösterdiği gibi bir engelden ziyade bir yardımdı.

Ek olarak, editörümün sözdizimini vurgulama kurallarını farklı renklerle gösterecek şekilde değiştirebildim, bu da kodun bilinmeyen bölümlerini (hatta kendi bölümümü) anlamaya çalışırken daha fazla görsel ipucu verdi.

Gerçekten Dylan'ın normal-normal-çizgi-onlar-için-kolay-türü-ve-kolay-okumak için seviyorum.

Sevmek

result-code := write-buffer(file-stream, some-string)

Ama bu dil oldukça belirsiz olduğu için sanırım bu konu dışı ... :(

CamelCase'i üniversitede kullanmam öğretildi. Son birkaç yılda birkaç farklı kongre kullandım, ancak CamelCase'i başka herhangi bir şey için tercih ettim. CamelCase'in aslında okuması ve anlaması en kolay olduğu bir yerde okuduğumu hatırlıyorum.

Çoğu insanın söylediği gibi - Mevcut standartı kullanın. Yeni bir proje ise, kullanacağınız dil ve çerçeveler için standardı kullanın.

Ve kafanız karışmasın, bu okunabilirlikle ilgili değil (özneldir), tutarlı ve profesyonel olmakla ilgilidir. Çok sayıda 'standart' olan bir kod tabanında çalışan herkes bunu anlayacaktır.

Bazen bir karışım kullanıyorum: module_FunctionName. Modüllerimdeki tüm (statik olmayan) işlevler, bir modül kısaltmasıyla başlar.

Örneğin, I2C veriyolunda arabellek içeriğini gönderme işlevi:

i2c_BufferSend()

Alternatif i2c_buffer_send, önek ile işlev adı arasında yeterince büyük bir ayrım göstermez. i2cBufferSendönek içinde çok fazla karışım var (bu modülde oldukça fazla sayıda I2C işlevi var).

i2c_Buffer_send Yine de bir alternatif olabilirdi.

Cevabım, projeniz için neyin en iyi şekilde işe yaradığına (diliniz, SW mimariniz, ...) adapte olmanız ve bu tarzları karıştırmanın yararlı olabileceğini belirtmek istedim.

myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.

Şahsen ben camelCase'i tercih ederim, ancak bazı fontlarda alt çizgi okunmasının daha kolay olduğunu düşünüyorum.

Değişken kümelerini ayırt etmek için ön ekler kullanmanız gerekirse, ad alanlarını veya nesneleri veya bu bilgileri saklamak için bir şey yapmanıza izin veren bir dil kullanmanız gerektiğini öneririm.

myName   = 7
bobsName = 8   // :(

me.name  = 7
bob.name = 8   // :D

Aynı şekilde, türleri ayırt etmeniz gerekiyorsa, neden onlara izin veren bir dil kullanmıyorsunuz?

var intThingy = 7; // :(

int thingy = 7;    // :)

Düzgün bir şekilde sahip olduğunuzda ve sadece meta-veri olarak ismi kullanmıyorsanız, o zaman fazladan tuşa basıp basmamayı tercih edip etmemenizin çok önemli olduğu yeterince uzun isimleriniz olmaz.

İlk başta dafmetal ile aynı fikirdeyim. Farklı programlama stillerini karıştırmamanız çok önemlidir. Bunu bir ve aynı dosyada yapmak IMHO'yu yapabileceğiniz en kötü şeydir. Farklı dosyalar arasında dikkat dağıtıcı, ancak ölümcül değil.

Yapmanız gereken bir sonraki şey, yazdığınız dil için popüler olan kuralları isimlendirmek. E-posta benim C ++ kodum, Python için açıkça farklı görünecek (PEP8 burada güzel bir rehberdir)

Farklı şeyleri belirtmek için farklı adlandırma kuralları da kullanabilirsiniz; sabitler için muhtemelen UPPER_CASE kullanıyorsanız (bu yalnızca elbette belirli diller için geçerlidir), this_style özelliğini yerel değişken adları için kullanabilirsiniz, oysa camelCase örneğini / üyesini kullanabilirsiniz değişkenler. Aşağıdaki gibi şeyler varken bu gerekli olmayabilir selfveya thisancak.

Güncelleme

Foo cadı platformunun isimlendirme kurallarını tavsiye etmediği ve takım liderinin seçeceği bir platform olduğu bir dava ele alalım. Siz o takım liderisiniz, neden camelCase'i seçtiniz veya neden undercore_case.

Biri diğerine göre hiçbir avantajı yok. Bu konu çok öznel ve bir zamanlar üzerinde anlaşmaya varıldığında, bir fark yaratmayacak. Bu küçük şeylerle ilgili her zaman bu dini savaşlar vardır. Ancak ikisinden birine adapte olduktan sonra, tartışmalar tamamen gereksiz görünüyor.

Alex Martelli'ye çok benzer bir konuda alıntı yapmak için:

Elbette, Ruby'de, her bloğun sonuna saçma bir "son" yazmaktan (sadece belirsiz değil) yazmaktan bıktım - ama sonra eşit olarak saçma ':' yazarak Python'un istediği gibi yazmaktan kaçınıyorum. başlangıç neredeyse yüzden her bloğun, bir yıkama :-). '@Foo' ile 'self.foo' ya da Ruby ile Python'daki durumun daha yüksek önemi gibi diğer sözdizimi farklılıkları da aslında benim için anlamsız.

Diğerleri hiç şüphesiz, programlama dillerini bu tür meselelere dayandırırlar ve en sıcak tartışmaları yaratırlar - ama bana göre bu, yürürlükte olan Parkinson Yasalarından sadece bir tanesidir ( bir konuyla ilgili tartışma miktarı, konuyla ters orantılıdır). gerçek önem ).

Kaynak

Takım lideri iseniz, sadece bir taneyle gidersiniz. Birinin diğerine göre bir avantajı olmadığından, sadece zar atıp istediğini seçebilirsin.

Birkaç yıl önce, İngilizce'yi ilk dil olarak konuşmayan programcıların, bu deve olayını anlamada altını çizme vakalarını daha kolay bulma eğiliminde olduğunu, ancak referansı bulamadığımı ve bunun doğru olup olmadığına dair hiçbir fikrim olmadığını okudum.

Java, Python, C ++ gibi kullandığım programlama dilleri için açık bir format kullandım:

• ClassNamesArePascalCase
• methodNamesAreCamalCase
• variable_names_are_underscore
• CONSTANT_VARIABLES_ARE_CAPITAL_VARIABLES

Bu, uğraştığım şeyi hemen ayırt etmeme izin veriyor. Kendim için sağlamanın yararlı olacağını ve kod okuyan bir başkası için izlemesi kolay olacağını buldum. Diğerlerinin de belirttiği gibi tutarlılığın en önemli olduğunu düşünüyorum. Bu yüzden, biçimimi korumak için yeterince basit ve isimler arasında net ayrımlar buluyorum. İnterface_Names_Are_Like_This ve Abstract_Classes_Are_Like_This arayüzünü olası uzantılar olarak hayal edebiliyorum, ama takip etmesi daha karmaşık görünüyor ve belki de yapması gereken bir ayrım gibi görünmüyor.

Ayrıca, PascalPase'de HTMLParser ya da HTMLparser yerine HtmlParser olarak HTML ayrıştırıcı gibi şeyleri adlandırmayı ve isim vermeyi faydalı buldum. Çünkü katı kuralı hatırlamanın daha kolay olduğuna ve kelime sınırlarını daha açık tuttuğuna inanıyorum (maalesef HTML veya SQL gibi yanlış yazım gerektiren şeyler). Benzer şekilde camelCase ile HTMLParserMethod veya HTMLparserMethod yerine htmlParserMethod.

GÜNCELLEME :

O zamandan beri özel değişkenleri içermek için bu kuralları genişletmede kullanım buldum. - _private_variable_names_are_prefixed_with_an_underscore - _PRIVATE_CONSTANT_VARIABLES_ARE_PREFIXED_WITH_AN_UNDERSCORE

Java'da bu, özel alanların tanım gereği yerel değişkenlerden farklı bir ad alanında olduğu anlamına gelir; bu this., özel alanları atlayabileceğiniz anlamına gelir . Ön eki " m" ile gördüm , ancak bu biçimler değişken adları için camelCase'i de kullanır. Bu aynı zamanda bana sadece sınıfın tarafından dahili erişilen (ve yapım gereken alanlar arasında bir ayrım yapmak için izin verir süper sınıfının dışında oluyor zaman açık object._field_xgöze çarpıyor).

Bana kalsa, herhangi bir stilin kullanılmasını zorlamaz ya da ipucu vermemeliydim, çünkü programcılar olarak bir sembol okuyabilirdik: IfIsInCamelCase veya in_underscore_space veya hatta in_SomeOtherStyle. Sembolü ayrıştırmak için çok az zaman harcamak zorunda olmak, işlerin büyük düzeninde büyük bir yük oluşturmaz.

Şimdi, sanırım bir kongre için temel argüman, bir işlev / değişken adının biçiminin ne olduğunu önceden bilmek ve onu aramak zorunda olmamanız gerektiğidir - LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file? Şimdi, bu iddiaya "İstihbarat tarzı otomatik tamamlamayı destekleyen bir IDE al!" Diyerek cevap verirdim. (her zaman mümkün olmasa da).

Sonunda, derleyici / tercüman için ne tarz kullandığınız gerçekten önemli değil. Önemli olan, ismin faydalı olması:

NumberOfPrisonersReleasedByAccident
manufacturer_name
distance_EarthToMoon

Üç farklı stil, ama her birinin ne yaptığını tam olarak biliyorsun.

Aptal görünebilir, ancak alt çizgi hoşuma gitmiyor, çünkü alt çizgi ince ve çok satırlı metinlerde gizleniyor ve özlüyorum. Ayrıca, bazı (birçok) metin editörlerinde ve / veya yazılım geliştirme ortamlarında, kopyalamak veya sürükleyip bırakmak üzere vurgulamak için bir belirteç adına çift tıkladığınızda, sistem tüm belirteçleri vurgulamaz, yalnızca bir kısmı vurgular belirteci, bitişik alt çizgiler arasında. Bu beni deli ediyor.

Gelişimimin çoğunu Eclipse'deki (Java, PHP ve JavaScript için) yaptığım aptalca bir sebepten dolayı camelCase'i tercih etme eğilimindeyim, ve kelimelerden Ctrl+ ←veya Ctrl+ →ile yazdığımda aslında camelCase sınırlarında duruyor.

Yani: myIntVariableEclipse tarafından Ctrl+ işaretlendiğinde 3 kelime olarak ele alınacaktı ← →.

Garip bir tuhaflık olduğunu biliyorum, ancak ortadaki kelimeleri camelCase adında düzenlemeyi tercih ediyorum.