Kısa tanımlayıcılar kötü mü? [kapalı]


26

Kısa tanımlayıcılar kötü mü? Tanımlayıcı uzunluğu kod anlama ile nasıl ilişkilidir? Tanımlayıcıları adlandırırken diğer hangi faktörler (kod anlama dışında) dikkate alınabilir?

Olduğunu Sadece cevapları yukarı kalitesini korumak notu memnun etmek denemek için bazı zaten konuyla ilgili araştırma!

Düzenle

Sağladığım her iki bağlantının da büyük tanımlayıcıların zararlı olduğunu göstermesi durumunda, herkesin uzunluğun alakalı olmadığını düşünmesi ya da daha büyük tanımlayıcıları tercih etme eğiliminde olduğunu merak ediyorum!

Kırık Bağlantı

Aşağıdaki link konuyla ilgili bir araştırmaya işaret ediyordu, ama şimdi kırıldı, kağıdın bir kopyasının yanımda olduğunu sanmıyorum ve ne olduğunu hatırlamıyorum. Başka birinin bulması ihtimaline karşı, burada bırakıyorum.


5
Veri noktası. En sevdiğim kısa tanımlayıcı :, olduğu gibi :(){ :;:& };:- Çoğu insanın oldukça kötü olduğunu düşündüğünü söyleyebilirim. ;)

@fennec: Çatal bombaları olma eğilimindedir.
Josh K,

Stackoverflow'un bu sorusunu kontrol edin , her programcının okuması gereken bir kitabı Programlama Uygulaması hakkında bir yorum var .
slu

1
Sadece daha uzun isimlerden kaçınılması gerektiği için, onları kısaltmak adına kısaltmak için fazladan çaba sarf etmeniz gerektiği anlamına gelmez.
JeffO

1
@ işlemci Komik ile ilgili olması amaçlanan bir şeyin kanaat temelli olarak kapatılmış olması komik. Ne yazık ki, aldığı cevaplar verilen kabul ediyorum.
Daniel C. Sobral,

Yanıtlar:


67

Duyduğum en iyi "kural", ad uzunluklarının değişkenin kapsamının uzunluğuyla orantılı olması gerektiğidir. Bu nedenle i, döngü gövdesi birkaç satır uzunluğundaysa, bir dizin iyidir, ancak 15 satırdan daha uzun olacaksa, biraz daha açıklayıcı bir şey kullanmayı severim.


6
Böyle bir şeyi hiç duymadım ve bu ilkenin kodun okunabilirliğini artıracağını sanmıyorum.
NimChimpsky

8
@Nim: Katılıyorum. Kısa bir fordöngüde bile , indeksi customerCounterveya başka bir şeyi adlandırırdım. Çok az çaba harcar ve kodunuzu çok daha iyi hale getirir. Kısa bir kapsam için kısa değişkenler kullanmak tembel olmak için bir bahane gibi geliyor.
Kimse

2
Hmm, bu benim için bir kural ya da rehber değil, uzunluğu hakkında düşündürmenin bir yolu ve bu bağlamda bir anlam ifade ediyor. Bunun tembellik için bir bahane olduğunu sanmıyorum (bazılarının böyle alabileceği konusunda hemfikir olduğum halde). Tanımlayıcılarım, 1, 2 veya 3 karakter tanımlayıcıların (genellikle ilk harflerin) bana mantıklı geldiği linq sorguları ve lambda ifadeleri gibi şeylere geldiğim zamanlar dışında (çok geçmeden paskal verildiğinin belirtileri) çok uzun sürelidir. .
Murph

33
+1 Dürüst olmak gerekirse "açıklayıcı" bir isim, döngü için beş satırdaki gürültüdür; Bence çoğu insan "ben" ile ne yaptığınızı çok iyi kavradı. İç içe döngülerde açıklayıcı adlar kullandım, ancak bunların daha uzun bir kapsamı var.
Jeremy,

18
+1 - Her geliştiricinin IMO'yu anlayabilmesi için ortak adlar kullanmak ive jbunları kullanmak .
TheCloudlessSky

48

Her değişkenin bir anlamı olmalı ve adı bu anlamın bir parçası. Ve çok önemli bir kısım, çünkü okuyucunun ne anlama geldiğini anlayabilmesi için algoritmayı derinlemesine incelemeye çalış. i, jendeks olarak kullanılacağı açık, kısa, ama çok bilgilendirici. bntçirkin closeveya closeButtonanlamlıdır. Bu yüzden kısa veya uzun olmak değişken ismi için en önemli kriter değildir, anlamlı olmalıdır. Anlamlılık, içeriğe kuvvetle bağlıdır. Örneğin n, kodun küçük bir satırında kullanılan, 10 satırlık ve özelliğin adını ifade eden yerel değer değişkenine çok kısa bir ad verebilirsiniz ( vdeğer başka bir örnektir).

Bu yüzden değişken isimleri bilgilendirici olmalı ve kısa ya da uzun olması önemli değildir .


2
+1, ve sadece not etmek gerekirse, close ve CloseButton da aynı şekilde değil. Kapat bir fiildir ve bu nedenle bir işlev veya yöntemin adı olmalıdır. CloseButton bir isimdir ve açıkça, close işlevini tetikleyen düğmenin adı olmalıdır.
CaffGeek

close bir sıfattır, örneğin close = true;)
Armand

13

Uzunluğa bakılmaksızın değişkeni tanımlayan bir tanımlayıcı kullanacağım.

İ, j ve k vakaları kendi içlerindedir, kendiliğinden tarif ettikleri her yerde, otomatik olarak döngü indeksleri olduklarını bilirsiniz. Ayrıca aynı şeyi söyleyebilirsin:

foreach loop (Strings s : myString)

Ancak, IDE'ler artık kod tamamlama araçları sağlıyor, böylece çok uzun ve tanımlayıcı tanımlayıcıların tek olumsuz yan etkisi afaik'ten kaldırıldı.

Değişkenin amacını açıklaması gerekirse, bir tanımlayıcıya mutlu bir şekilde ekleyeceğim.


3
BTW, i, j ve k döngü döngüleri için kullanılması FORTRAN'a 50+ yıl öncesine dayanıyor. N ile başlayan harflerle başlayan değişkenler varsayılan olarak INTEGER türündedir. Başka bir harfle başlayan değişkenler, varsayılan olarak GERÇEKTİR. Bu, doğal olarak döngü indeksleri için I, J ve K kullanımına yol açtı. (FORTRAN sözleşmesi muhtemelen matematik denklemlerinde bu değişkenlerin kullanılmasından önce ortaya
çıkmıştır

2
Bağladığım ikinci makale, çok uzun tanımlayıcı tanımlayıcıların, “sadece olumsuz yan etki” sözleriyle çelişen, kodu anlama yeteneğini azalttığını göstermiştir.
Daniel C. Sobral,

3
Çok uzun tanımlayıcıların gerçek olumsuz yan etkisi okunabilir durumda. Bir bakışta iki çok uzun tanımlayıcının aynı mı yoksa farklı mı olduğunu söylemek zor ve bir ifadenin tüm öğelerini çok uzun tanımlayıcılarla seçmek zor olabilir.
David Thornley

tcrosley - Fortran'dan geldiği için böyle bir uygulamaya devam etmek için hiçbir sebep olmadığını eklerdim. "İ", "j", "k" vb. Yinelemeli / döngü sayaçlarının kullanılmasını kesinlikle önermiyorum. Bu basit bir entelektüel tembellik. Ubiquitous <> iyi.
Çabuk_

9

Yanıltıcı tanımlayıcılar kadar kötü değiller. Tanımlayıcıların yalnızca bir harf olduğu hata ayıklama kodunu dikkate almıyorum, ancak şu an farklı adlandırma kuralları resme girdiğinde can sıkıcı oluyor. Örneğin, gördüğünüz bir yerde strPersonIDve sonra başka bir yerde gördüğünüzde s_EmployeeID, bu iki dizenin de olup olmadığını ve herhangi bir fark olup olmadığını söylemek kafa karıştırıcıdır. Ayrıca değişkenler kopyala yapıştırılmış ( pmapIntString = new std::map<int,int>) ve tamamen yanlışsa, endişeleneceğim.

Bana gelince, kullanılan önemli değişkenler için kodda yorumlar ekliyorum ve geliştirme kılavuzunda verilen standardı korumaya çalışıyorum. Standart yoksa o zaman kod boyunca aynı adlandırma kuralını yerine getirmeye çalışırım.


5

Mücadele ediyorum ...

Her zaman tanımlayıcı adları tanımlayıcı olarak kullanmak için kullanıyorum, ancak daha sonra çok kısa tanımlayıcılar kullandım.

Kodun içeriğine bağlı olduğunu düşünüyorum:

  • Yazma işleminiz karmaşıksa (algoritmalar), HER ZAMAN kısa tanımlayıcıları kullanın (tek karakterler en iyisidir)
  • Fonksiyonlar için Parametre değerleri yazarken tanımlayıcı isimler kullanın.

Sanırım kodun ne kadar yoğun olduğuna da bağlı. Bazen isimlere sahip olmak aslında okumayı zorlaştırır.

Bazen isimler olmadan tamamen şifreli!


1
Yine de karmaşık algoritmalar yazıyorsanız, tanımlayıcıların kodunuza ilk kez bakan insanlar için daha açıklayıcı olmasını istemez miydiniz?
Saat

Tek bir karakter tanımlayıcı ne zaman uygun olur?
Amir Afgan

1
Bunu düşünmek için de kullanıyorum, ama aslında bunun böyle olmadığını buldum, kendiniz deneyin. Karmaşık bir algoritma alın ve tek harfli değişkenlere karşı tanımlayıcı isimleri deneyin.
Darknight

1
Katılıyorum, ancak daha uzun ve karmaşık formüller için, çünkü onlar çok uzama eğilimindedirler ve hatta o zaman bile formülün hangi kısımlarını tanımlamak için fonksiyonlar kullanabilirsiniz.
Emile Vrijdags,

1
Eğer bu kadar karmaşıksa ve kalıpları varsa, bu kalıpların fonksiyonlara bölünmesi gerekir
CaffGeek

3

Benim düşüncem, kendi içlerinde fena olmadıkları, ancak çok standart olmadıkça, bilgi vermeyen olmalarıdır.

Dolayısıyla, i, j ve k olmak üzere döngü değişkenleri o kadar standart ki indeksli bir döngü oluşturuyorsanız bunları kullanmamak için hiçbir sebep yoktur.

Çok kısa bir tanımlayıcı kullanacağım diğer yer ise, birkaç satırda kapsam dışına çıkacak geçici bir değişken ilan ettiğimde, örneğin bir foreach döngüsündeki geçici değişken. Başka bir yere yönlendirilmeyecekse, kodu okuyan herkesin bildirimi görmesi ve ne için kullanıldığını takip etmesi kolaydır. Beş veya altıdan fazla satır için kullanılacaksa, daha net bir isim vermek için bakacağım.

Bilgilendirici uzunluk tanımlayıcıları kullanmaya çalıştığımın ötesinde - özellikle sınıf düzeyinde, değişkenin ne için olduğu hakkında bir şeyler okuyup öğrenebileceğiniz bir tanımlayıcı istiyorum. Eğer çok uzarlarsa (ve bazen bir tanımlayıcı için dizilmiş dört veya beş kelimeyle kod görüyorum) bir kod kokusu gibi görüyorum - değişkenlerimi ayırt etmek için bu kadar metne ihtiyacım olursa aslında hashmap veya listede daha iyi saklanabilir mi? Bu verileri daha doğru bir şekilde modellemek için bir tür nesne oluşturabilir miyim? Bazen yapamazsınız ama çok uzun bir tanımlayıcı burada bakılmaya değer bir şey olduğunu gösterir.


3

Buradaki diğer cevaplara çok katılıyorum, ancak genellikle göz ardı edildiğini düşündüğüm başka bir faktöre dikkat çekmek istiyorum. İyi bir ad genellikle koda aptal olan bir isimdir. Bu, bir dil seviyesi, algoritma seviyesi veya eldeki kod temeli için bazı dahili deyimler olabilir. Mesele şu ki, isim kodun alanını bilmeyen birisine hiçbir şey ifade etmiyor olsa da, yine de verilen bağlamdaki en iyi isim olabilir.


3

Bir değişkeni adlandırmak her zaman benzersizliği ve anlaşılırlığı dengelemek için bir uygulamadır. İsmin uzunluğu farklı şekillerde ikisiyle de ilgilidir. Daha uzun isimler benzersiz yapmak daha kolaydır; orta uzunluktaki isimler, çok kısa veya çok uzun olan isimlerden daha anlaşılır olma eğilimindedir.

O anlaşılır hale getirir öyküsü varsa çok kısa bir değişken ismi yararlıdır (örneğin, i, j, ve k; indeksleri için dxtüm referanslar kez görünür olması için yeterince küçük ya da bir kapsamda bir eksen boyunca bir mesafe) (örn , temp). Dünyadaki en kötü değişken isimleri gibi şeyler t47. ("Bu ne anlama geliyor ve neden farklı t46?") Şükürler olsun ki, FORTRAN ile isimlendirme tarzı daha da yaygınlaştı, ama bu daha uzun değişken isimleri arzusunun kök saldığı yer.

Orijinal makalenizin gösterdiği gibi, çok uzun isimlerin okunması da zor, zira kodlara göz atarken ince iç farklılıklar eksik olabilir. ( DistanceBetweenXAxisAbscissae& Arasındaki fark DistanceBetweenYAxisAbscissaehızlı bir şekilde tespit etmek gerçekten zor.)

NoteToSelf'in daha önce de belirttiği gibi, bir ismin benzersizliği gereklilikleri, öncelikle ismin benzersiz olması gereken alana bağlıdır. 5 satırlı bir döngünün indeksi i; fonksiyondan fonksiyona geçen aktif bir kaydın indeksinin daha açıklayıcı bir ismi olması daha iyiydi.

Bir fonksiyona lokal değişken, deltaXproblemsiz gibi küçük bir tanımlayıcı isme sahip olabilir . Bir modüldeki statik delta X değişkeni, bu deltaX'ı aynı modüldeki diğer deltaX'lerden ayıran ve daha uzun hale getiren bir ada sahip olmalıdır. Ve genel bir delta X değişkeni, muhtemelen modül adını diğer açıklayıcı isimle birleştirerek tüm modüllerde ve yaratılabilecek tüm diğer modüllerde benzersiz yapılmalıdır. Bu, küresellerle ilgili birçok problemden biridir; Faydalı şekilde benzersiz olması için, adların okunmasını zorlaştıracak kadar uzun olması gerekir.


2

Aksine, uzun tanımlayıcıların kısa tanımlayıcılardan daha kötü olduğunu düşünüyorum (sabitlerle uğraşmıyorsanız). Kullanmak TheVariableThatHoldsTheCapacityOfMyContainerClass, kodunuzu kullanmaktan çok hatalara yatkın hale getirir Capacity.


1
Bağlantılı olduğum araştırmalardan birinin, aynı nedenlerle olmasa da, mantığınızı desteklediğini bilmek sizi mutlu edecektir. ;-)
Daniel C. Sobral,

1
Aynı zamanda, çok uzun tanımlayıcıları yanlış okumak, muhtemelen kafa karıştırıcı ya da ikisinin aynı olduğunu anlamayı başaramamak çok kolaydır.
David Thornley,

2
TheVariableThatHoldsTheCapacityOfMyContainerClass "uzun" olarak düşündüğümden daha büyük - on sözcük CamelCase'in yardım etmesi için çok uzun; okunabilir hale getirmek için boşluklara ihtiyacınız var.
Richard Gadsden,

1
Tabii, ama bu saman adam. Uzun bir ismin örneğiniz, kelime bilgisi ekler ancak bilgi içermez. Çeşitli kapasite biçimleriyle ilgili birden fazla değişkeniniz olduğunu düşünün. O zaman gerçekten, initalCapacity veya finalCapacity gibi amaçları ayırt eden isimler isteyebilirsiniz.
Charles E. Grant

2
@Maxpm, var total = Capacity + Capacity2; Ne Capacityiçerir ve ne Capacity2içerir? Ne için kullanılacaklar? Bağlam ipuçlarına bakmak zorunda kalmak zaman harcar. Oysa var totalStorageCapacity = truckCapacity + trailerCapacity;neyden bahsettiğimizi bildiğim gibi yazılmışsa .
CaffGeek

2

İçinde ve kendilerinde kısa tanımlayıcılar fena değil. İyi isimler seçmenin amacı (kısa veya uzun) açıklığı kodlamak için hizmettedir. Kod netliği hizmetinde tanımlayıcıları seçmek, bazı minimum uzunluk gereksinimlerini karşılamaktan daha önemlidir. Genel olarak bunun anlamı, biraz daha uzun anlamlı adlar yazmaktır.


+1 çok iyi söyledin, cevabımı yazdığımda sözlerimi bulamadım :-)
ComputerSaysNo

1

Yıllar boyunca yaşadığım ve bugün 10 veya 15 yıl öncekinden daha az bugün olduğu bir gözlem. Yazamayan programcılar, değişken adlandırma üzerine diş ve çivi ile savaşacak olanlardır. 1-3 harf değişkeni adlarına sahip olanlardır.

Bu yüzden tavsiyem, birçok yorumcunun söylediği gibi anlamlı bir isim kullanmak ve sonra da yazmayı öğrenmek. Sadece insanların nerede olduğunu görmek için röportajlara bir yazma testi eklemeyi düşünüyordum, ancak bilgisayarlar toplumun daha büyük bir parçası haline geldiğinde, daktilo olmayanların çok daha azını görmeye başladım.


2
Aslında böyle bir ilişki görmedim. Bir şey görünüyorsa, OO dillerinden insanlar uzun tanımlayıcılar için gider ve fonksiyonel dilden insanlar kısa olanlar için gider. OO'nun modellemeye yardımcı olduğu iddiasını sorgulamaktadır. :-)
Daniel C. Sobral,

Unutmayın, adların sadece yazılı değil, aynı zamanda okunması gerektiğini de unutmayın. Çok uzun tanımlayıcıların kullanılması, okunabilirliği gerçekten çok azaltabilir. Bir şey dışında ancak ibir döngüde kullanmak for (int i=0; i<dst.size(); ++i) dst[i] += src[i]yasalarca yasaklanmalıdır.
maaartinus

1

Bağladığınız ilk makale ilginç görünüyor, ancak sonucu, anlamlı değişken isimleri de dahil olmak üzere "topraklama ipuçlarının" kodun kavranmasına yardımcı olduğu hipotezi için veya kanıtlarına karşı önemli bir kanıt bulamadıklarıdır. Kullanılmış bakış, ilginç, ancak bir smaç değil, kod anlama için bir vekil olarak kalıyordu.

Korkarım ikinci kağıdı sadece saçma buldum. İlk sorun, sağladıkları uzun adların örneklerinin hiçbir ek bilgi sağlamadığı için boş yere uzun olmasıdır. Sanırım hepimiz daha uzun yapmak için değişken bir isim yapmanın aptalca olduğu konusunda hemfikir olabiliriz. Dx yerine distance_between_abscissae değişkenini adlandırmaya ilişkin örnekleri saman adamıdır.

Daha da önemlisi, deneyleri anlamadan ziyade basit bir ezber testidir. Bu bir listede sunulduğunda değişken adının parçalarının eksik doldurmak için deneklerin yeteneğini test eden hiçbir bağlam. Evet, daha uzun isimleri ezberlemek daha zordur, ancak kod yazarken değişken isimlerini ezberlemem, bunları bağlam sağlamak için kullanırım. Sanırım, uzun değişkeni hatırlamanın zorluğunun kod yazmayı zorlaştırdığını, ancak kodun yazıldığından çok daha sık okuduğunu iddia edersiniz, bu nedenle hangi etkinlik optimize edilmelidir?


İkinci yazının açıkça belirtildiği gibi, "Sekiz soruda kullanılan sekiz isim üretim kodundan çıkarılmış." Ayrıca, sadece ezberlemek için test değil, aynı zamanda doğruluk için de test yaparlar.
Daniel C. Sobral

1

Bir kod satırının okunup okunamayacağını belirleyen ana ölçütlerimden biri, satırın ne yaptığını anladığınızdan emin olmak için diğer satırlardan ne kadar başka bağlamın okunması gerektiğidir.

"Herkesin i, j ve k'nin döngü değişkenleri olduğunu anlayabilmesi" demek kolaydır. Ve çoğu zaman gerçekten çok açık. Ancak yine de bu konuda mütevazi ve profesyonel kalmaya çalışıyorum ve programlamada hata yapmanın kolay olduğunu kabul ediyorum. Bu yüzden bir Grobbles dizisi arasında döngü yapıyorsam, grobbleIndex döngü değişkenini adlandıracağım. Ayrıca indeksi kısaltması olarak kabul edebilirim. İj ve k kullanırken, yanlış diziyi yanlış diziyle kullanmak gibi bir hatayı bulmak daha zordur. Ve içsel bir döngünüz olduğunda daha da kötüleşiyor.

PS. Bu cevabı yazdığımda, dikey olarak bölünmüş bir ekrana sahip 10 inçlik bir mini dizüstü bilgisayar üzerinde bazı javascript kodlamıyordum ve yine de döngü değişkenlerimi rowIndex ve columnIndex olarak adlandırmaya zaman ayırdım.


0

Bazı uygulamalarda kısa bir değişken değişkendeki verileri açıklayamaz. Kısa ya da uzun konu dışı. Daha uzun bir değişken kullanmak kodunuzu yavaşlatmaz. Elbette uzun değişkenli bir isim yazmak daha zordur ancak en azından 6 ay sonra kodu okuyan kişi (ki siz olabilirsiniz), bunun mümkün olduğunu varsayarak iz bırakmaya gerek duymadan ne olduğunu çözebilir.


0

Ben İdeal isimleri açıklayıcı olması gerektiğini düşünüyorum sürece ...

İsimlerin daha kısa olabileceği düşüncesi (belki de) daha kısa olabilir - ve bu nedenle daha az tanımlayıcıdır - sınırlı bir kapsamları varsa , idealden sapmanın sadece bir nedenidir.

Şahsen ben sık sık az sayıda tekrar tekrar başvuruda bulunulan varlıklar için kısa adlar kullanırım. Örneğin, uygulamaya özel alt rutinler denir.


-2

Asla 4-5 karakterden az tanımlayıcı isimleri kullanmam, örneğin bir döngü değişkeni bir şeyi başarmak için kaç tane iç döngü kullanmam gerektiğine bağlı olarak Index veya jIndex veya kIndex olabilir, fakat diğer isimler için kullanacağım bir "anahtar" diyelim. "String LKey" veya "int LKey", "L", yerel bir yöntem değişkeni ise, "L" veya özel sınıf değişkeni için "F" ise, benden önce belirtilenler gibi diğer tüm tanımlayıcılar, ismindeki varlığının nedenini açıklamalıdır; "tanımlayıcı" kapsamı işe yaramaz değil mi ?!


5
"İndex" "i" nin vermediği hangi ek bilgileri veriyor? Size hiçbir şey söylemeyen uzun değişken isimleri, tek karakterlerden daha kötüdür.
Anon.

2
Son zamanlarda bir 3d ızgara üzerinde çalışan bazı şeyler yazdıktan sonra, x, y ve z adlı birçok değişken var. Bağlam göz önüne alındığında, tamamen açıklayıcı idi.
Loren Pechtel
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.