Adlandırma kuralınız dilinizle çakıştığında ne yaparsınız?


14

Tamam, bu beni hep rahatsız eden küçük şeylerden biri. Tipik olarak tanımlayıcıları kısaltmam ve kısa bir tanımlayıcı (örn. i) Kullandığım tek zaman dar bir döngü içindir. Bu yüzden C ++ ile çalıştığımda beni rahatsız ediyor ve adlandırılması gereken bir değişkenim var operatorya da classbunun etrafında çalışmam ya da bir kısaltma kullanmam gerekiyor, çünkü yapışıyor. Dikkat: bu benim başıma orantısız bir şekilde gelebilir çünkü programlama dili tasarımında çok çalışıyorum, burada etki alanı nesneleri ana bilgisayar dilinde kavramları yansıtabilir ve yanlışlıkla çatışmalara neden olabilir.

Bununla nasıl başa çıkardınız? Kısaltmak? ( op) Yazım hatası? ( klass) Başka bir şey mi? ( operator_)


7
Ad boşluklarının yanı sıra, adlandırma kurallarımızı değiştirmeyi düşünmeliyiz? Açıkçası için özür dilerim.
Chris

1
@Chris: Bariz olanı gerçekleştirmek için asla bir programcıya güvenemezsin! (Bu durumda ben varım.)
Jon Purdy

7
PHP'nin $varsözdizimini sevmek için herhangi bir neden varsa, işte budur .
Joey Adams

3
@Joey Adams: Bu soruyu görünce kısaca gülümsedim ve SE etrafında yüzen tüm PHP dayak sorularını hatırladım.
Chris

3
Açıkçası, adlandırma kurallarına izin vermek için dil kaynak kodunu değiştirin. Bu sadece benim yorumcum / derleyici üzerinde çalışacağı / derleyeceği için kodumu "koruma" avantajına sahiptir.
dietbuddha

Yanıtlar:


21
  1. Büyük harf ekleme gibi adlandırma kuralınızda küçük değişiklikler yapmanız gerekebileceğini kabul edin. Bunu mümkün olan en kısa sürede kabul etmek daha iyidir, böylece sonraki tüm kodlar tutarlıdır.

  2. Daha spesifik olmayı düşünün. Anahtar kelimeler öylesine daralan oldukça geniş olma eğilimi classaşağı demonstrationClasskonular etrafında çalışır kalmaz, aynı zamanda okunabilirliği artırır.


10

Karşılaştığım bir şey değil, ama böyle bir duruma girersem, sırayla, aşağıdaki seçeneklerle çözmeye çalışacağım.

  1. Bir eşanlamlı bulmaya çalışın.
  2. (özellikle değişkenler için) bir önek veya postfix bulmaya çalışın
  3. (özellikle sınıflar için) ilk harfi büyük harfe çevirin ve kodlama kuralını unutun. Bu seçenek, muhtemelen yalnızca çakışma bir anahtar kelimeyle kullanılıyorsa kullanırım.
  4. Bir kısaltma kullanın.

1
Sadece durum parametresinin const Foo&dışında herhangi bir makul tam adı olmadığı argüman listelerinde, sadece durumda farklı isimler ile neyin yanlış olduğunu görmüyorum foo. Kabul edilirse, bir işlev gövdesinde yaşıyor ve daha az özel bir amaca hizmet ediyor Fooolmasından daha açıklayıcı bir ad vermek daha iyi olabilir foo.
Jon Purdy

@Jon - Katılıyorum, ancak şahsen büyük / küçük harf değişimi yerine "p_", "l_" ve "m_" öneklerine yöneliyorum. Bu sözleşmeyi, hepsi aynı olan-açık-isim sorunu nedeniyle kabul ettim. Bununla başa çıkmak için hangi sözleşmeyi kullandığınız, elbette belirli bir bağlamda tutarlı olarak kullandığınız sürece, büyük ölçüde önemsizdir - elbette - vaka değiştiren yaklaşım, çoğu geliştiricinin bunu tanıması için yeterince geniş bir şekilde kullanılmaktadır.
Steve314

@Jon - Bu yorum, sadece aynı isimlerle ilgili konuyu seçtiğimde konvansiyonu seçmeli olarak uyguladığım gibi geliyor, ki bu demek istediğim değil. Bağlam konusu dil, proje vb. İle ilgilidir. Kurallar, gerektiğinde seçici olarak uygulanmayacak şekilde, meydana geldiğinde (ya da daha doğrusu) sorunun bir sorun olmayacağı şekilde tasarlanmıştır.
Steve314

@ Steve314: İlk yorumdan anlamını aldım. Bilmiyorum, böyle ekler rahatlığım için her zaman Systems Hungarian'a çok yakın geliyordu.
Jon Purdy

@Jon: Dini olarak uyguladığım bir kural değil, ancak iki tanımlayıcı yalnızca durum farklıysa hata yapmanın daha kolay olduğunu düşünüyorum. Bu hatalardan bazıları derleyici tarafından tespit edilir, bazılarını bulmak daha zordur (özellikle iki tanımlayıcı aynı türden isimler veriyorsa). Her türlü istisna dışında, olası tüm vakaları kapsayan tam bir kitap değerinden daha genel bir kurala sahip olmayı tercih ederim.
Bart van Ingen Schenau

6

Dil kazanır; derleyiciyi alt edemezsiniz (PL / 1 gibi iğrençlikleri yok sayarak IF IF = THEN THEN THEN = ELSE ELSE ELSE = IF END, ancak PL / 1 ilk etapta soruyu sormanıza neden olmaz). Temel olarak, dil kurallarına uymanız ve kendi kullanımınız için dilin anahtar kelimelerine bir alternatif bulmanız veya alternatif bir dil bulmanız gerekir.

Yani, çok olağandışı durumlar dışında, dile değil, dile uyum sağlıyorsunuz.


5

Kısaltmak yerine uzatmaya ne dersiniz? Foo dilinde bir sınıf yapısı uyguluyorsanız, FooClass ve foo_class kullanmaya ne dersiniz? (Kasa tercihleriniz ne olursa olsun Modulo).


Java kodunda kullandığınız her tanımlayıcıya "java" ön eki ekler misiniz? Ve hatta her tanımlayıcıda "C ++" ön
eki

@ Steve314, java kodunda java önekini kullanmazsınız, bir java derleyicisini uygulayan c ++ kodunda java önekini kullanırsınız. Ayrıca, yalnızca tanımlayıcının geri kalanı bir anahtar kelime olduğunda kullanabilirsiniz.
Winston Ewert

Tamam - tanımlayıcının da neyi ifade ettiği konusunda daha spesifik olduğu için genel anlamda uzatma demek istediniz. Farklı uygulamalar için, "class", "class_taught" veya "class_of_animal" veya "classiness_value" olarak adlandırılabilir. Katılıyorum - Derleyici odaklı örneği kafa karıştırıcı buldum.
Steve314

5

classSıklık sırasına göre kullandığım bazı kısaltmalar :

  • cls
  • clss
  • clazz
  • theClass
  • aClass

ClassÖrneğin hangi sınıfı temsil ettiğini biliyorsanız , bunu değişken adına dahil edebilirim:

  • stringClass = Class.forName("java.lang.String");

Daha önce bunun için hiç 'cls' görmedim. Çoğunlukla aClass kullanıyorum.
Konstantin Petrukhnov

4

C ve C ++ 'da, anahtar kelimelerin tümü küçük harf ve dil büyük / küçük harfe duyarlıdır, bu nedenle shift tuşuna zaman zaman basın ve birçok sorun ortadan kalkar.

Modula 2'de, anahtar kelimeler tüm büyük - ama bu kadar uzun tanımlayıcıları sahip olarak bazı küçük harfleri fark açıktır ve imkansız çatışmalarda.

Ayrıca, kesinlikle isimlendirme kuralları bir dereceye kadar kullandığınız dilin normal kurallarını yansıtmalıdır, bu yüzden kesinlikle C ++ 'da "My_Class" yazacağım Java'da "myClass" yazacağım.

Temel olarak, sadece derleyici için yazmıyorsunuz, ancak insanların okunabilir buldukları bir dereceye kadar bağlama ve ilgili beklentilere bağlı.


3
Büyük / küçük harfe duyarlı diller için bile, karıştırılmış classve Classkodun okunabilirliğine zarar vereceğini hissediyorum .
Karmastan

@Karmastan - belki de büyük / küçük harfe duyarlı diller ve sözleşmelerle çalışmak için ne kadar zaman harcadığınıza bağlıdır. Şahsen, büyük ve küçük harf "C" görsel olarak çok açık - uzun tanımlayıcılar için vaka kullanım modellerini okuyabildiğimden daha hızlı görüyorum.
Steve314

3

Ben sık sık bu rastlamak değil, ama ben Delphi kullanmak ve tanımlayıcı bir & ekleyerek bu soruna geçici bir çözüm sağlar çünkü ben bunu yaparken bir sorun olmaya meyilli. Yani "class" geçerli bir tanımlayıcı değil, "& class".


İlginç. Bir tanımlayıcı kullanılabilecek her yerde dize değişmez değerleri sağlayan bir kod oluşturma yardımcı programı var. Başlangıçta, oluşturulan kodun çoğu tanımlayıcısı, büyüyen (ve anahtar kelime açısından zengin) bir DSL ile anahtar kelime çakışması riskini önlemek için dize değişmezleri olarak yazılmıştır. Şimdi, tanımlayıcılar çoğu ad için kullanılır (kaynağın bu şekilde ne kadar okunabilir olması şaşırtıcıdır), ancak dize değişmezleri her zaman bir yedek olarak kullanılabilir. Kod üretimi için iyi olduğunu düşündüm, ancak anahtar kelime çakışması geçici çözümleri genel amaçlı bir dilde kötü bir fikir olurdu - ama belki de yanılıyorum.
Steve314

2

Değişken adına bir tür ad alanı eklerdim. Örneğin, kullanıcı adında bir modülünüz olduğunu varsayalım, o zaman değişken adı operatörünü user_operator veya userOperator gibi bir şey olarak değiştiririm.


2
önek olarak "düzgün", "hayır" veya "benim" kullanmayın
Steven A. Lowe

2
Kesinlikle. "Jon_Purdys_Carefully_Chosen_Identifier_Prefix_" oyu veriyorum.
Steve314

1
@Steven: Daha da kötüsü, görüyorum a, anve theacemi CS öğrencileri tarafından frekansı rahatsız ile kullanılabilir.
Jon Purdy

1
@Jon Purdy, bu bizim hatamız değil! People () sınıfı örneklerini adlandırmaya karar veren profesörü suçlayın aPerson.
Ben L

@Jon: Çalıştığım adlandırma kuralı, yerel değişkenlerin asıkı döngü değişkenleri dışında başlaması gerektiğini belirtir : /
Matthieu M.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.