it-swarm-tr.com

Döngülerde / istisnalarda değişken adları için tek karakterler kullanma

İş arkadaşımızla, kod tabanımızdaki bazı durumlarda tek harfli değişken adlarının kullanımı hakkında her ikimiz de aynı fikirde olmadığımız birkaç tartışma yaptım.

Bunlar için daha ayrıntılı adlandırma kuralını tercih ediyor ve ben yapmıyorum.

Kanımca tek harfli değişken adları kullandığım üç senaryo var:

  • Döngüler - ifor(int i = 0; i < 10; i++) { ... }
  • C #'daki Lambda ifadeleri - x/y/z: .Where(x => x == 5)
  • İstisnalar - e: try { ... } catch(ExceptionType e) { /* usage of 'e' */ }

Bunlar onu kullanacağım sadece senaryoları ve başka yerlerde açıkça daha ayrıntılı adlandırma kuralları kullanıyorum.

Meslektaşım istisnalar ve döngüler için aşağıdaki argümanları öne sürdü:

  • i - hiçbir şey ifade etmiyor.
  • e - İngilizce dilindeki en yaygın harf. Çözümü istisnalar için aramak isterseniz, istenmeyen birçok e örneği bulacaksınız.

Bu argümanları kabul ediyorum, ancak bir for döngüsünde i'in ne anlama geldiğini bilmiyorsa, muhtemelen bir programcı olmamalıdır. e gibi döngüler ve istisnalar için çok yaygın bir terimdir. İsterseniz, istisna durumunda catch arayabileceklerini de belirttim.

Bunun öznel olduğunu anlıyorum, ancak o zaman kodlama standartlarının sadece akademisyenler tarafından da olsa görüşler olduğunu iddia edebiliriz.

Her iki şekilde de mutlu olurum ve sonuçları ona iletirim, ancak biz (şirketimiz) ne kullanacağımız konusunda farklı görüşlere sahip iki geliştiriciye sahip olmak yerine tek bir kodlama standardı kullanmaya devam etmeyi tercih ederiz.

68
Dan Atkinson

Fikrinize tamamen katılıyorum ve hepsinin that öznel olmadığına inanıyorum.

Bir değişkenin adı yalnızca kapsamı ile ilgilidir.

Bir değişkenin adı hakkındaki sonsuz tartışmalarda, yalnızca o küçük kapsamlı kod parçasını okuyan bir kişi tarafından okunacak bir anlamı yoktur. Öte yandan, sınıf adları ve üye adları neler olup bittiğini açıkça belirtmelidir. Beklenen davranışların birçoğunun özlü bir adla açıklanması gerekir.

Sözleşmeler okunabilirliği artırır.

i ve e bu küçük kapsamlandırılmış değişkenler için kullanılan yaygın kurallardır. Sözleşmeyi biliyorsanız, niyetleri gerçekten açıktır.

Kısaca okunabilirliği artırır.

Niyetini açıkça temsil eden kısa bir değişken adı, büyük bir değişken adı yerine tercih edilmelidir.

83
Steven Jeuris

Bu gerçekten duruma/bağlama bağlıdır (ve hepsine uyan hiçbir çözüm yoktur .

Genel olarak i, j, k [btw, idizin olarak alınabilir; kullanımı en sık ilk üç indeks olan matematiksel arka plandan gelir (tensör hesabını hatırlayın). Ayrıca Fortran'ın geçmişine de bağlanabilir, burada i ilk örtülü olarak yazılan tamsayı olmak, genellikle bir döngü dizini olarak kullanılır. ] genellikle basit bir sayaçsa kullanılır. ay veya yıl gibi belirli bir anlamı varsa, daha uzun değişken adı daha iyidir.

54
Rook

Size katılıyorum: i bir döngü değişkeni adı, kimseyi karıştırmaması gereken eski bir deyimdir. Bir catch bloğundaki istisna değişkeni için e ile aynı. İkincisi (veya her ikisi de) kısa ve basit olmalıdır, bu da değişkenin kapsamını küçük hale getirerek, okuyucular için karışıklık olasılığını sınırlar. Birisi istisnaları aramak istiyorsa, istisna türlerini daha iyi arayın veya yine de blokları yakalayın.

Bu, kişisel olarak index veya idx gibi daha uzun döngü değişken adları kullanmayı tercih ettiğimi söyledi. Benim nedenim i çok kısadır, imleçle bulmak zordur.

Güncelleme

Referans olarak, iş arkadaşınızın argümanları muhtemelen Ottinger'in İsimlendirme Kuralları - konuya mükemmel ve pragmatik bir yaklaşım, okuma için önerilir. Ancak, aşağıda belirtilen bölümleri gözden kaçırmış olabilir:

Kişisel tercihim, tek harfli adların SADECE yerel değişkenler kısa yöntemler. Bir adın uzunluğu bir şekilde kapsamının boyutuna karşılık gelmelidir. Bir değişken veya sabit kod gövdesinde birden çok yerde görülebiliyor veya kullanılabiliyorsa, ona arama dostu bir ad vermek zorunludur.

Ve

Kesinlikle bir döngü sayacı, kapsamı çok küçükse ve başka ad yoksa hiçbir zaman i veya j veya k olarak adlandırılabilir (asla l!) onunla çatışabilir. Bunlara izin verilir, çünkü bunlar geleneksel çözüm etki alanı adlarıdır.

24
Péter Török

daha ayrıntılı isimler de aynı derecede anlamsız olabilir. "i" çok basit bir yineleme sayacı olarak kullanılır, neredeyse standart bir uygulamadır. Bazı "kodlama standardı" tek harfli değişken adlarını yasakladığı için aynı sayacı "iter" olarak adlandırmak herhangi bir değer katmaz.

"x", "y" ve "z" standart koordinat adlarıdır ve bunları xCoord, yCoord, zCoord olarak adlandırırlar.

"e" elbette matematiksel bir ifadedir. Ancak, Java'daki catch bloklarındaki istisnalar için bir ad olarak kullanılması nispeten yaygındır. Buna "exc" ya da benzeri bir şey denildiğinde yine gerçek bir değer olmaz.

15
jwenting

Döngü değişkenleri için bile anlamlı değişken isimlerini tercih ederim. Bu yüzden genellikle şöyle bir şey yazarım

for (int vertexIndex=0; vertexIndex<polygon.VertexCount; vertexIndex++)
   DoSomethingWithVertex(polygon[vertexIndex]);

Böyle küçük bir döngü için (her iki şekilde) çok az fark olduğunu fark, ama:

  • döngü gövdesi daha uzunsa, vertexIndex genellikle i'den daha açıktır. Elbette i bir indeks, ama hangi indeks? Hangi diziye? Bu dizideki hangi öğeye?
  • döngü gövdesi diğer işlevleri çağırır ve dizini bağımsız değişken olarak iletirse, değeri arayan ve callee konumlarında tutarlı bir şekilde adlandırmak genellikle daha kolaydır ve i ve x yöntem parametrelerini çağırmak istemezsiniz.
  • iç içe döngüler varsa, endeksler çok değişken ve hataya açık olduğu için i, j, k kullanarak

tutarlı olmak için, her yerde döngü indeksleri için sadece anlamlı değişken isimleri kullanıyorum.

@ André Paramés sordu: "Döngü gövdesi i'nin anlamını gizleyecek kadar uzunsa, yeniden düzenleme zamanı değil mi?"

Tipik bir insan beyninin kısa süreli hafıza kapasitesi yaklaşık 7 veri parçasına sahiptir. Eğer döngü gövdesi 8 veya daha fazla parça içeriyorsa ("parçalar" ifadeler, yerel değişkenler, parametreler, yorumlar ise), beyniniz bu parçaların her birinin anlamını aynı anda depolayamaz. Bunun yerine, kodu okurken beyniniz parçaları çalışan belleğin içine ve dışına kaydırır. Örneğin, i ve j gibi değişken adları kullanırsanız beyniniz i ve j'nin anlamlarını çalışma belleğinden kaydırır; j'yi bir dahaki sefere okuduğunuzda, beyniniz genellikle anlamını bulmak için bağlama bağlıdır; yani döngü gövdesinin ortasında customers[j] okursanız, beyniniz çıkarımj, customers dizisinin bir dizinidir. customers[vertexIndex] Yazsaydınız, yanlış dizini kullandığınızı görürsünüz. Ve bu sadece 8 bilgi parçalı, yani 5-8 satır kodlu çok kısa döngü gövdeleri için.

Gövde uzarsa, genellikle vertexIndex parametresiyle ayrı bir işleve çıkarırsınız. Ve işte ikinci nokta bu: Eğer değişken bu fonksiyonun içinde vertexIndex olarak isimlendirilmişse, gerçekten de arayanda vertexIndex olarak adlandırılmalıdır.

15
nikie

Meslektaşlarınızın puanlarına katılmıyorum.

Benim için "yineleme" demek istiyorum. Bir döngü durumunda oldukça anlamlı.

Çoğu IDE metin içinde normal ifade tipi aramaya izin verir. Böylece bir Word içinde değil 'e' kelimesini arayabilirsiniz. Bu etkili olur.

10
TZHX

Kısa değişken isimleri doğal dillerdeki zamirler gibidir: küçük bir bağlamda/kapsamda kullanılır. "i" kısa bir döngü (yuva yok) veya "e" birkaç yakalama dizisi mükemmel tamam. Birçok durumda "i" için uzun/açıklayıcı ad "the_stupid_index_needed_to_get_at_the_really_interesting_things" olur ve lambda ifadesini yalnızca bir bağlamda gerekli olduğu için kullanırsınız.

Perl's $ _ çalışan bir süper zamandır (Perl programcıları için); 'it' bile atlamasına izin verildi/cesaretlendirildi (sadece "print $ _" e "print") biraz korktuğum bir şey.

Koddaki sorunları tespit etmek için değişken isimlerini aramak benim ilk fikrim değil. Programcı, belirli bir sorun durumunda nereye bakılacağını sınıf veya işlev hakkında bir fikre sahip olmalıdır.

6
Ekkehard.Horner

(Bu .NET merkezli ama sorunuz C # lambda ifadelerinden bahsetti, bu yüzden sizin durumunuzla alakalı olduğunu düşünüyorum.)

ex zaten bir olay işleyicisi için e türü argümanı olarak (WinForms ve ASP.NET WebForms kuralları tarafından) kullanıldığından, her zaman bir istisna için EventArgs kullanırdım.

örneğin.

protected void button_Click(object sender, System.EventArgs e)
{
    try
    {
        // whatever
    }
    catch (Exception ex)
    {
        // some exception handling
    }
}

Ancak MSDN, istisna değişkenleri için e kullanır.

Bu tartışma sırasında iki şeyi akılda tutmanızı öneririm:

  • Değişken adlandırma kuralları genellikle dini savaş şeklinde düşünülebilir.
  • En önemli kodlama kuralı mevcut kodun stilini korumaktır.
6
Richard Ev

Burada herhangi bir soru görmüyorum, ancak "i", "j" genellikle "x" ve "y" (kişisel tercihim) gibi koordinatlara atıfta bulunur, "e" nin çok yaygın olabileceğini anlıyorum, ancak İstisnalar aranıyorsa, "İstisna" aramasına jus.

tek harfli değişkenleri kullanmanın en büyük sorunu, bunlarla karıştırılabilmenizdir, ancak bu değişkenin bir döngüde veya bir deneme yakalamasında olduğu gibi sınırlı bir kapsamı varsa, onunla herhangi bir sorun görmüyorum

5
IvoC

Tek bir döngünüz olduğunda genellikle çok alakalı değildir ve basitlik için (ve kural nedeniyle) i veya j'yi kullanmayı tercih ederim. İç içe döngü ile, bazen hangi dizinin neyle ilgili olduğunu tanımak için daha ayrıntılı adları kullanırım. Örneğin, iki dizim varsa: tarihler ve nicelikler ve ilk tarihler ve sonra miktarlar üzerinde yinelenen bir iç içe döngü var, karışıklığı önlemek için dateIdx ve quantityIdx adlarını kullanırdım. Yazarken kodumda hatalar var

matrix[i][j] = fun(dates[i], quantities[j]);

ama olmalı

matrix[i][j] = fun(dates[j], quantities[i]);

Daha ayrıntılı isimlerle, hatayı kolayca tespit ederim,

matrix[quantityIdx][dateIdx] = fun(dates[quantityIdx], quantities[dateIdx]);

sadece yanlış gözükür.

5
quant_dev

İlginç bir epistemolojik soru anlamı. Meslektaşınız, bir şeyin ona bir şey ifade ettiği için, o zaman is anlamı olduğunu varsayıyor gibi görünüyor.

Gerçek şu ki, sadece programlamada değil, her gün kullandığımız tüm semboller, sadece onu onlara atfettiğimiz için anlam taşıyor. Ya da, farklı bir şekilde ifade etmek gerekirse, anlamı beyninizde, değil sembolünde. (Bunu açıklığa kavuşturmak için çivi yazılı bir tablet düşünün - elbette yazarlar için bir zamanlar anlam ifade ediyordu, ancak bugün milyarlarca insanın çoğu için böyle bir şey yoktu.)

Bunun ışığında, uzun isimlerin bir şey ifade ettiği varsayımı, kısa isimler anlama gelmezse saçmadır. Dahası, bir program metnindeki uzun bir adın bir şekilde muhtemelen farklı bir bağlamda sahip olduğu anlamı taşıması beklentisi karışıklığa yol açabilir.

4
Ingo

Birkaç nokta:

  • Ben "ii" için "i" kullanmayı tercih gerektiğini önerdi duydum çünkü eğer döngü dizini aramak zorunda kalırsanız bunu yapabilirsiniz (ve genel olarak daha görsel olarak farklı), ve Bence bu iyi bir fikir.
  • Döngünüzün kapsamına ve içeriğine bağlıdır. Döngünüz basitçe 10 kez bir şey yapıyorsa (örneğin, döngü değişkenine bile erişmiyorsa), o zaman "i" veya "ii" nin daha uzun bir addan bin kat daha makul olduğunu düşünüyorum. Hiç programlamış olan herkes "i" den daha iyi bilmeli veya öğrenmelidir "normalde" döngü değişkeni "
  • Döngünüzün içinde büyük bir ish kod bloğu varsa, bunu bir işleve çıkarmayı düşünün, ancak her iki durumda da kısa ama anlamlı bir ada sahip olmanız değerli olabilir, örn. carIdx veya day, en azından döngünün gövdesinde "i" kullanmak isteyebileceğiniz için.
  • Döngünüz bir veri yapısının içeriği üzerinde döngü oluşturuyorsa, ilgili bir ad kullanın: veri türünün veya değişkenin makul bir şekilde ayırt edici olması durumunda (değişken otomobillerde her araç için) bir kısaltma veya küçük harf formu veya döngünüz ise daha uzun bir form daha karmaşık.
  • Aynı şeyin daha az tanıdık olmasına rağmen lambdalar ve istisnalar için de geçerli olduğunu düşünüyorum. Örneğin, IS lambda'nıza giriş için mantıklı bir ad varsa, özellikle birden fazla varsa, o zaman kullanın, ancak çoğu zaman bir lambda'nın tüm NOKTASI Herkesin "x" i çok iyi anlamasını anladığı anonim bir girdi alır.
4
Jack V.

Okunabilir kod hakkında konuşurken, dikkate almanız gereken birkaç şey var:

  • Kodlama standartlarınız nelerdir?
  • Platformunuz için ortak sözleşmeler nelerdir?
  • Karışıklık potansiyeli var mı?

Kodlama standartlarınızın değişken isimlendirme kuralları hakkında fazla bir şey söylemediğini varsayarsak, kodu tartışmayı düşünmelisiniz. Örneğin, aşağıdaki döngü ile:

for(int i = 0; i < 10; i++)
{
    function(i);
}

Döngü ve tüm fonksiyonları, kapsamının tamamı için açıkça görülebilir. Şimdi, iç içe döngülerimiz olup olmadığını düşünün (benim favorim bir döngü içindeki bir döngü içindeki döngüdür); veya 100 satıra yayılan bir döngü olabilir. Bu noktada, tek harfli yineleyiciler pek mantıklı değil, çünkü kapsamda kaybolmak çok kolay. Biraz evcilleştirmek için 100 kod satırını bazı yöntemlere/işlevlere yeniden yönlendirmek, ancak dizine anlamlı bir ad vermek isteyebilirsiniz.

İstisnalar söz konusu olduğunda, e 'ın sadece iyi bir isim olmadığını kabul etme eğilimindeyim. Ancak, nedenlerim arkadaşınızınkinden farklı. Java yıllar boyunca programlama yaptım ve birisi Java Bir istisna ele alırken, istisna işlemenizin bir kısmını başka bir istisna işleyicisine kapsüllemeniz gerekir, bunun sık karşılaşılan bir yeri JDBC kodudur.

Alt satır, kontrol ettiğiniz her istisnanın benzersiz bir ada ihtiyacı olduğundan ve bir deneme yan tümcesinde çeşitli hata türlerini işlediğiniz için, bu istisnalara bir şey ifade eden isimler verin. e, e1, e2 kodu okurken yardımcı olmuyor. Ne tür bir istisnaya bakıyorum? Yine, karışıklık için yer olduğu için uzun isimler kullanın.

4
Berin Loritsch

i döngülerini yalnızca şu durumlarda bir sayaç olarak kullanıyorum:

  • bir indeks olarak kullanılır; ve
  • kapsamı çok kısa olduğunda.

Rook'un dediği gibi, i terimi, bir programlama kuralı olarak etiketlenen bir dizin olarak matematiksel bir arka plana sahiptir. Ancak, birçok değişken içeren uzun bir döngü ise, sayacı i daha açık bir şeye yeniden adlandırırdım. Örneğin bir matris üzerinde yinelenen iç içe döngüler varsa, genellikle row ve col tam olarak açık olmadığından i ve j kullanırım artık ne kastettiklerini ("Bu A[i][j] veya A[j][i]...? ").

e ile ilgili istisnalar için ex kullanma eğilimindeyim çünkü e için element kullanıldığını gördüm.

3
gablin

"Ne yapıyorsun?" vs. "Bunu nasıl yapıyorsun?"

Her şeyden önce, mümkünse, foreach yerine for kullanın. Ne yaptığınızı daha iyi ifade eder (yani koleksiyonda yürüyün ve her bir öğeyi işleyin.) Bu, adlandırma sorununu tamamen ortadan kaldırır.

Dizin değişkeninin "the_stupid_index_needed_to_get_at_the_really_interesting_things" dışında bir anlamı varsa (teşekkürler E.H.) bu anlamı kullanın. row ve col, i ve jeğer yerine dizi bir tabloyu temsil ediyor olmalıdır. Çok fazla takas yapıyorsam position veya pos kullanmayı da seviyorum.

Ancak, for (int i = 0 ....) deyim o kadar iyi yapılandırılmıştır ki, bir yineleme için fiili standarttır. İyi bir sebep olmadan köklü bir deyimle uğraşmayın.

Yukarıdaki istisna: Matematik veya Fizik - Metinden standart formülleri kullanın.

v = d/t; Bir fizikçi veya mühendis için velocity = distance / time;

2
Chris Cudmore

"İ" kullanmakta sorunum olmasa da, kondisyon standartları daha fazlasını gerektiriyor. Gerekli olup olmadığını tartışarak zaman kaybetmezdim. Benim için "loopIndex" ve "loopCounter", "i" yerine kullandığım iki standart isim.

1
DPD

@ nikie bazı argümanlarımı listeledi, ancak ayrıntı düzeyini sınırlama argümanınızın zayıf olduğunu eklemek istiyorum.

Koda ayrı ayrı bakıldığında, daha açıklayıcı bir ad yardımcı olacaktır. Döngünün kendisini tanımlamak sizin bahsettiğiniz gibi bir sorun değildir.

Bir uygulamada birçok kez 'i' kullanacaksınız ve bazı yazımları kaydedebilirsiniz, ancak hepsi aynı şeyi ifade etmez. Birçok SQL komut dosyası, bir tabloyu tek harfli olarak takma adlandıracaktır, ancak her kullanıldığında aynı tabloya atıfta bulunur.

Anlamlı isimlerle gelmek zor olabilir, bu yüzden onu alışkanlık haline getirmek en iyisidir.

1
JeffO

İçin "e", elbette "istisna" veya "hata" anlamına gelir, istisnaları aramak kolaydır, aramanızın tüm kelimelerle eşleştiğinden emin olmanız gerekir (ayrıca "e)" kelimesini eşleşen tüm kelimelerle de arayabilir. değişken ve parantez arasında boşluk kullanmazsanız), istisna işleyicileri dışında pek çok "e" bulamazsınız.

İçin "i", bir anlamı vardır: "yineleyici" (veya muhtemelen "dizin" veya "artırıcı") anlamına gelir.

Kısa bir değişken adına sahip olmanın başka bir nedeni daha vardır: bir çerçevede çok sık kullanılan veya neye sahip olduğunuz daha uzun değişken/sınıf adları için kısayollar. JQuery "$".

1
Phoenix

i 'artış' anlamına geldi. Bence çok sayıda farklı cevap, değişken isimlerin anlamlılığı hakkında orijinal soruda bir şey olduğunu gösteriyor - genellikle geleneksel bir şey ifade ediyorlar, ancak birçok insan geleneğin ne olduğunu bilmeden kullanıyor. i 'in ne anlama geldiğini bilmeyen birinin "programcı olmamalı" olduğunu söylemek kolaydır, ancak nasıl öğrenirsiniz i ne anlama geliyor? Burada yarım düzine cevap var.

1
David Rhoden

Code Complete'teki Steve McConnell, değişken adlarının ayrıntı düzeyi için büyük tavsiyelerde bulundu, hepsi değişkenin kapsamına ve kullanımına bağlı. Büyük bir sınıfınız varsa, dosyanın değişkeninin kodunun yarısına gömüldüğünüzde değişkenin neyi temsil ettiğini bilmek istediğiniz için üye değişkenlerinizin adları net olmalıdır. Kısa bir fonksiyonunuz veya sadece birkaç satır kod için kullanılan bir değişkeniniz varsa, tanımlandığı yer veya neyi temsil ettiği konusunda kafanız karışmayacağından istediğiniz kadar kısa yapabilirsiniz ve daha küçük bir ad kodu oluşturur net.

Bu nedenle sizin durumunuz için, i, e ve x büyük değişken isimleridir. (elbette büyük karmaşık döngüleriniz olmadığını varsayarsak)

1
Richard