Yaklaşık 2 yıldır underscore_case kullanıyorum ve son zamanlarda yeni iş nedeniyle camelCase geçti (yaklaşık 2 ay için sonraki bir kullanarak ve hala underscore_case dahil programcılar bir sürü büyük projeler için daha uygun olduğunu düşünüyorum, çünkü kodun okunması daha kolaydır).
Artık işteki herkes camelCase kullanıyor çünkü kod daha zarif görünüyor.
CamelCase veya underscore_case hakkında ne düşünüyorsunuz?
not; lütfen kötü ingilizcemi affedin
Düzenle
Önce bazı güncellemeler:
kullanılan platform PHP (ama katı PHP platformla ilgili cevaplar beklemiyorum), herkes hangi en iyi kullanmak olacağını düşüncelerini paylaşabilir, bu neden ilk etapta buraya geldim)
CamelCase'i takımdaki diğer herkes gibi kullanıyorum (çoğunuzun tavsiye ettiği gibi)
camelCase'i de öneren Zend Framework kullanıyoruz
Bazı örnekler (PHP ile ilgili):
Codeigniter çerçevesi underscore_case önerir ve dürüstçe kodun okunması daha kolaydır.
ZF camelCase'i tavsiye eder ve ZF kodunun takip edilmesinin biraz daha zor olduğunu düşünen tek kişi ben değilim.
Yani sorum yeniden ifade edilecekti:
Herhangi bir adlandırma kuralı önermeyen Foo platformuna sahip olduğunuz bir durumu ele alalım ve takım liderinin bir tane seçmesi bu. Bu takım lideri sizsiniz, neden camelCase'i seçiyorsunuz veya neden underscore_case?
not; Şimdiye kadar İstemi yanıtlar için herkese teşekkürler
Bunun bir dereceye kadar kullandığınız dile bağlı olduğunu kabul ediyorum; Sembol adlarınız, dilin yerleşik ve stok kitaplıklarıyla aynı biçimlendirme rejimini izlediğinde kod daha düzgün görünme eğilimindedir.
Ama bir seçenek olduğunda, basit bir nedenden ötürü alt çizgileri deve kasasına tercih ederim: Bu stili okumayı daha kolay buluyorum. İşte bir örnek: Hangisini daha okunabilir buluyorsunuz? Bu:
aRatherLongSymbolName
veya bu:
a_rather_long_symbol_name
Alt çizgi sürümünü okumayı çok daha kolay buluyorum. Beynim, özellikle sınırların karşı durumun diğer gliflerine veya sayılarına benzeyen glifler arasında olduğu durumlarda, deve kasasındaki küçük/büyük sınırları algılayabildiğinden alt çizgileri çok daha kolay görmezden gelebilir (
I/l,
O/0,
t/I Vb.). Örneğin, bu boole değişkeni, bir Igloo'nun uygun planlama izniyle inşa edilip edilmediğini gösteren bir değeri saklar (şüphesiz hepimiz için ortak bir kullanım durumu):
isIllicitIgloo
Bu sürümü bir lot okunması daha kolay buluyorum:
is_illicit_igloo
Belki de okunması zor bir sembol adından daha da kötüsü, yanlış okunması kolay bir sembol adıdır. İyi sembol isimleri kendi kendini belgelendirir, bu da bana göre onları bir bakışta okuyabilmeli ve anlamlarını anlayabilmen gerekir. (Eminim hepimiz zevk için yatakta kod çıktılarını okuyoruz, ama bazen de acele ediyoruz.) Sık sık deve vaka sembol isimleri ile onları yanlış okumak ve yanlış bir izlenim almak kolay buluyorum sembolün semantiği.
Platformunuz tarafından kabul edilen adlandırma kuralını kullanmanız gerektiğini düşünüyorum. underscore_case = Ruby =) içindeki camelCase gibi C # kodunda tuhaf görünecek
Dürüst olmak gerekirse, takımdaki herkes aynı şemayı kullandığı sürece gerçekten önemli değil. Şansın biri ya da diğeri sizin için daha doğal olsa da, gerçek önem kodun uzun vadede okunabilirliği ve o zaman herkesin aynı adlandırma kurallarına uyması çok önemlidir.
Bir cevaba dayanarak John Isaacks'ın cevabı:
"dürüstçe kodu okumak daha kolay" Görüş ya da gerçek?
Biraz araştırma yapmaya karar verdim ve buldum bu makale . Bilim bu konuda ne söylemelidir?
Konuyla ilgili blog yazım 'da bilimsel makaleyi inceliyorum ve aşağıdaki sonuca varıyorum.
Deve davasının sadece yavaşlığı (2), diğer noktaları ilgisiz olarak programlamaktan, modern IDE'ler ve camelCase kullanıcılarının çoğunluğu çalışmada. Tartışma (bir anketle birlikte) blog yayınında bulunabilir.
Bu makalenin fikirlerini nasıl değiştirebileceğini merak ediyorum. :)
En Akıllı Adamları Kopyala
Programlama dilleri söz konusu olduğunda, dilin geliştiricisinin stilini kopyalayın.
Örneğin C'yi aynen K&R'de olduğu gibi kodlarım.
Sonra kimse sıkıcı bir kodlama tarzı konuşma başlatmaya çalıştığında, onlara “bunu Dennis Ritche ile getirin ve ne dediğini bana bildirin” diyebilirim.
Genel olarak, camelCase'i tercih ederim. Ancak, kariyerimin çoğunun, stil kılavuzlarının normalde camelCase'i önerdiği dillerde ve ortamlarda çalışıyorum. (Java, ECMAScript, C++). PHP kişi olarak), bunun tersi bir tercihiniz olabilir.
Bununla birlikte, üçOrFourWords'ün ötesine geçtiğinizde veyaXmlForExample gibi başlatmalar kullandığınızda, okunabilir durumda kalmaz.
Bu yüzden emacs bize gözlük modu veriyor.
camelCase
Bu, okunabilirlik konusunda her zaman 'tip yeteneği' seçeceğim birkaç yerden biri. CamelCase'in yazılması daha kolay ve parmaklarıma daha hoş olmak benim için hafif bir okunabilirlik kazancı kazanıyor.
elbette projenin farklı bir standarda sahip mevcut bir kod tabanına dayanmadığını varsayarsak.
Bu ilginç bir soru, bunu birçok kez düşündüm. Ama kesin bir cevap yok sanırım.
"Kültürel" sözleşmeleri takiben iyi bir seçim. "Kültürel" bu durumda 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_names işlev işlevleri/"korumalı" yöntemler için ve Java stili
methodNames yöntemler için. Ekibim bundan memnun oldu :)
Programlama diline bağlıdır.
Davayı, Macarca gösterimi kullanıp kullanmama konusunda aynı teknede kullanmayı düşünüyorum:
CakePHP'de çok fazla geliştirme yapıyorum ve
CamelCase veya
$underscored_vars Yöntemini aşağıdaki şekilde (CakePHP Projelerinin dışında bile) kullanıyorum:
/lowercased_underscored.phpTipik, ancak belirtmeye değer.
class CamelCase extends ParentObject.
CamelCasekullanırken, ilk karakterin küçük harf olmadığını unutmayın. Ben gerçekten tuhaf bakmak için
camelCasebuluyorum.
$are_variables_underscored === TRUE;
$CamelCase = new CamelCase();
$collection['underscored_keys'];
ALL_CAPS_AND_UNDERSCOREDolması gerektiğine katılabilir.
$CamelCase->foo_method_underscored();
CamelCase::just_like_regular_methods();
Şahsen
underscore_case çünkü daha okunabilir buluyorum, ancak mevcut kod tabanı ile tutarlılığın çok daha önemli olduğunu belirten diğer cevaplayanlarla aynı fikirdeyim.
Ancak, "dilinizin ve kütüphanelerinin kurallarına uyun" diyenler için bir karşı örnek var.
Geçmişte
underscore_case ve
PascalCase Win32 işlevleri olarak adlandırılır:
if (one_of_our_conditions_is_true()) { call_one_of_our_functions(); CallSystemFunction(); }
İşlev adlarımız ile Microsoft'un işlev adları arasındaki görsel ayrım, kodun "sistem alanına" ne zaman girildiğini açıkça gösterdiğinden, engel olmaktan ziyade bir yardımcıdır.
Buna ek olarak, editörümün sözdizimi vurgulama kurallarını farklı renklerde görüntülemek için değiştirebildim, bu da kodun bilinmeyen bölümlerini (hatta kendi bölümlerimi) anlamaya çalışırken daha fazla görsel ipuçları verdi.
Dylan'ın yazması kolay ve okunması kolay olduğu gibi normal çizgilerini gerçekten çok seviyorum.
Sevmek
result-code := write-buffer(file-stream, some-string)
Ama sanırım bu dil oldukça belirsiz, bu bir tür konu dışı ... :(
Üniversitede camelCase kullanmam öğretildi. Son birkaç yıldır birkaç farklı sözleşme kullandım ama camelCase'i başka herhangi bir şeye tercih ettim. Sanırım camelCase'in aslında okunması ve anlaşılması en kolay olan bir yerde okuduğumu hatırlıyorum.
Şahsen, camelCase'i tercih ediyorum, ancak bazı yazı tiplerinde alt çizgilerin okunmasının daha kolay olduğunu düşünüyorum.
Değişken kümelerini ayırt etmek için önek kullanmanız gerekiyorsa, ad alanları veya nesneler veya bu bilgileri tutacak bir şey yapmanıza izin veren bir dil kullanmanız gerektiğini öneririm.
myName = 7 bobsName = 8 // :( me.name = 7 bob.name = 8 // :D
Benzer şekilde, türleri ayırt etmeniz gerekiyorsa, neden onlara izin veren bir dil kullanmıyorsunuz?
var intThingy = 7; // :( int thingy = 7; // :)
Bu düze sahip olduğunuzda ve sadece adı meta veri olarak kullanmıyorsanız, o ekstra tuşa basmayı tercih edip etmemeniz önemli olan yeterince uzun isme sahip olmayacaksınız.
Çoğu insanın belirttiği gibi - Mevcut standardı kullanın. Bu yeni bir projeyse, kullanacağınız dil ve çerçeveler için standardı kullanın.
Ve kafa karıştırmayın, bu okunabilirlikle ilgili değil (ki bu özneldir), tutarlı ve profesyonel olmakla ilgilidir. Çok sayıda 'standart' olan bir kod tabanında çalışan herkes anlayacaktır.
Bazen bir mix kullanın: module_FunctionName. Modüllerimdeki tüm (statik olmayan) işlevler bir modül kısaltmasıyla başlar.
Örneğin, I2C veri yolunda bir arabellek içeriği 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östermiyor.
i2cBufferSend önekte çok fazla karışıyor (bu modülde oldukça fazla I2C işlevi var).
i2c_Buffer_send olsa da, bir alternatif olabilir.
Cevabım, projeniz için en uygun olana (diliniz, SW mimariniz, ...) uyum sağlamanız ve bu stilleri karıştırmanın yararlı olabileceğine işaret etmek oldu.
myGeneralOpinionIsThatNamesAreMuchHarderToReadInCamelCase. I_respect_the_fact_that_some_could_think_otherwise_but_I_do_not_really_understand_why.
Java, Python, C++ gibi kullandığım programlama dilleri için net bir biçim benimsedim:
Bu, neyle uğraştığımı hemen fark etmemi sağlar. Kendimi korumak için yararlı olduğunu buldum ve kodu okuyan bir başkası için takip etmek kolay olmalı. Diğerlerinin de belirttiği gibi tutarlılığın çok önemli olduğunu düşünüyorum. Bu yüzden formatımı, isimlerin türleri arasında net ayrımlar sağlarken, sürdürülebilecek kadar basit buluyorum. Interface_Names_Are_Like_This ve Abstract_Classes_Are_Like_This'i olası uzantılar olarak hayal edebiliyorum, ancak takip etmek daha karmaşık ve belki de bir ayrım yapmak için kullanışlı görünmüyor.
Ben de HTMLParser veya HTMLparser yerine HtmlParser gibi bir HTML ayrıştırıcı gibi PascalCase katı şeyler ve isim şeyler yararlı buldum. Çünkü katı kuralı hatırlamanın daha kolay olduğuna ve Word sınırlarını daha net tuttuğuna inanıyorum (maalesef HTML veya SQL gibi yazım hatalarını gerektiriyor). Benzer şekilde camelCase ile HTMLParserMethod veya HTMLparserMethod yerine htmlParserMethod.
[~ # ~] Güncelleme [~ # ~] :
O zamandan beri bu değişkenleri özel değişkenleri içerecek şekilde 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, özel alanlarda
this. 'Yu atlayabileceğiniz anlamına gelir. Diğer biçimler "
m" ile önek gördüm, ancak bu biçimler de değişken adları için camelCase kullanıyor. Bu aynı zamanda sadece sınıf tarafından dahili olarak erişilmesi gereken (ve süper sınıfın dışında gerçekleştiğinde açıklığa kavuşturmamı sağlayan alanlar arasında bir ayrım yapmamı sağlıyor.
object._field_x Öne çıkıyor).
İlk başta dafmetal ile hemfikirim. Farklı programlama stillerini karıştırmamanız son derece önemlidir. Bunu bir ve aynı dosyada yapmak IMHO yapabileceğiniz en kötü şey. Farklı dosyalar arasında dikkat dağıtıcıdır, ancak ölümcül değildir.
Yapmanız gereken bir sonraki şey, yazdığınız dil için popüler olan kuralları adlandırmaktır. İnstnace için C++ kodum, Python açıkçası (PEP8 burada güzel bir rehber)
Farklı şeylere atıfta bulunmak için farklı adlandırma kurallarını da kullanabilirsiniz, sabitler için UPPER_CASE kullandığınız sürece (bu yalnızca elbette belirli diller için geçerlidir), yerel değişken adları için this_style'ı kullanabilirsiniz, oysa örnek/üye için camelCase kullanırsınız değişkenler. Ancak
self veya
this gibi şeyleriniz olduğunda buna gerek olmayabilir.
Foo cadı platformunun herhangi bir adlandırma kuralını tavsiye etmediği ve takım liderinin bir tane seçmesinin bulunduğu bir duruma bakalım. Bu takım lideri sizsiniz, neden camelCase'i seçiyorsunuz veya neden underscore_case.
Birinin diğerine göre avantajı yoktur. Bu konu çok özneldir ve üzerinde anlaşmaya varıldığında, bir fark yaratmaz. Bu küçük şeyler hakkında her zaman bu iğrenç savaşlar vardır. Ama ikisinden birine uyum sağladıktan sonra, tartışmalar tamamen gereksiz görünüyor.
Alex Martelli'ye çok benzer bir konuda alıntı yapmak için:
Tabii, Ruby'de, her bloğun sonuna aptalca "son" yazarak (sadece isteksiz olmaktan ziyade) yorgunum - ama sonra eşit derecede aptalca yazmaktan kaçınıyorum ':' which Python her bloğun başlangıç gerektirir, bu yüzden neredeyse bir yıkama :-). '@Foo' ve 'self.foo' gibi diğer sözdizimi farklılıkları veya Ruby Python'a karşı davanın yüksek önemi) gerçekten benim için önemsizdir.
Diğerleri şüphesiz, programlama dillerini seçtikleri bu tür sorunlara dayandırıyorlar ve en sıcak tartışmaları üretiyorlar - ama bana göre bu, Parkinson Yasası'ndan birinin ( tartışılan miktarın sadece bir örneği bir konuda, konunun gerçek önemi ile ters orantılıdır ).
Takım lideri iseniz, sadece bir tane ile gidersiniz. Birinin diğerine göre herhangi bir avantajı olmadığından, zar atabilir veya daha fazlasını isteyebilirsiniz.
Birkaç yıl önce, ilk dil olarak İngilizce bilmeyen programcıların, bu deve durumunu anlamak için alt çizgi durumunu daha kolay bulma eğiliminde olduğunu okudum - ancak referansı bulamıyorum ve bunun doğru olup olmadığı hakkında hiçbir fikrim yok.
Bana kalmış olsaydı, herhangi bir stilin uygulanmasını zorlayamazdım veya ipucu vermezdim çünkü programcılar olarak, IfItIsInCamelCase veya in_underscore_space veya hatta in_SomeOtherStyle sembolünü okuyabilir ve bunun ne anlama geldiğini anlayabilirdik. Sembolü ayrıştırmak için çok az zaman harcamak, şeylerin büyük düzeninde büyük bir yük oluşturmaz.
Şimdi, bir kuralın ana argümanı, bir işlev/değişken adının formatının ne olduğunu önceden bilmeniz ve aramanıza gerek yoktur - LoadXMLFile, loadXMLFile, LoadXmlFile, load_xml_file mı? Şimdi, bu argümanın karşılığını alıyorum "Al IDE intellisense tarzı otomatik tamamlamayı destekleyen!") (Her zaman mümkün olmayabilir).
Sonunda, derleyiciyi/yorumlayıcıyı gerçekten önemsemediği için hangi stili kullandığınız önemli değildir. Önemli olan adın yararlı olması:
NumberOfPrisonersReleasedByAccident manufacturer_name distance_EarthToMoon
Üç farklı stil, ancak her birinin ne yaptığını tam olarak biliyorsunuz.
Eclipse (Java, PHP ve JavaScript) için benim geliştirme çoğunu yaptığım aptalca neden camelCase tercih eğilimindedir ve ne zaman Ctrl+← veya Ctrl+→ kelimelerle, aslında camelCase sınırlarında durur.
Yani:
myIntVariable Eclipse tarafından 3 kelime Ctrl+← →içinden geçiyor.
Garip bir tuhaflık olduğunu biliyorum, ama kendimi bir camelCase adındaki orta kelimeleri düzenlemeyi tercih ettiğimi görüyorum.
Aptalca görünebilir, ancak alt çizgileri sevmiyorum çünkü alt çizgi ince ve birden çok satır metninde gizleniyor ve özlüyorum. Ayrıca, bazı (çok) metin editörlerinde ve/veya geliştirici ortamlarında, bir belirteç adını kopyalamak veya sürükleyip bırakmak için çift tıklattığınızda, sistem tüm belirteci vurgulamaz, yalnızca bir bölümü vurgular belirteci, bitişik alt çizgiler arasında. Bu beni deli ediyor.