Kısa değişken isimleri için bir bahane var mı?

Bu şu anda üzerinde çalıştığım kod temeli ile büyük bir hayal kırıklığı yarattı; değişken isimlerimizin çoğu kısa ve açıklayıcı değildir. Projede kalan tek geliştiriciyim ve çoğunun ne yaptığıyla ilgili belgeler yok, bu yüzden temsil ettiklerini izlemek için fazladan zaman harcamak zorundayım.

Örneğin, bir optik yüzeyin tanımını güncelleyen bazı kodları okuyordum. Başlangıçta ayarlanan değişkenler aşağıdaki gibidir:

double dR, dCV, dK, dDin, dDout, dRin, dRout
dR = Convert.ToDouble(_tblAsphere.Rows[0].ItemArray.GetValue(1));
dCV = convert.ToDouble(_tblAsphere.Rows[1].ItemArray.GetValue(1));
... and so on

Belki de sadece benim, ama esasen neyi temsil ettikleri hakkında hiçbir şey söylemedi, bu da kodun anlaşılmasını zorlaştırdı. Tek bildiğim, belirli bir tablodaki belirli bir satırdaki belirli bir satırdan ayrıştırılan bir değişken olduğuydu. Biraz araştırdıktan sonra ne anlama geldiklerini öğrendim:

dR = radius
dCV = curvature
dK = conic constant
dDin = inner aperture
dDout = outer aperture
dRin = inner radius
dRout = outer radius

Onları esasen orada olanlara göre yeniden adlandırdım. Bazı çizgileri uzatıyor, ancak bunun adil bir işlem olduğunu hissediyorum. Bununla birlikte, bu tür bir isimlendirme şeması, çoğu kod boyunca kullanılmaktadır. Eski sistemler ile çalışarak öğrenen geliştiricilerin bir eseri olup olmadığını ya da arkasında daha derin bir sebep olup olmadığından emin değilim. Değişkenleri bu şekilde adlandırmak için iyi bir neden var mı, yoksa karşılaştığım gibi onları daha açıklayıcı adlara güncellemede haklı mıyım?

Bu değişken adlarının, çeşitli optik problemlerinde çalışan bir fizik ders kitabında bulmayı beklediğiniz kısaltmalara dayandığı anlaşılmaktadır. Bu, kısa değişken isimlerinin genellikle daha uzun değişken isimleri tercih ettiği durumlardan biridir. Rin, Rout, vb. Gibi genel kısaltmaları kullanmaya alışmış fizikçileriniz (veya denklemleri el ile çalıştırmaya alışkın insanlar) varsa, kod, bu kısaltmalar ile daha uzun değişken isimlerden daha açık olacaktır. Ayrıca, kodun aslında hesaplamaları doğru yaptığından emin olmak için kağıtlardan ve ders kitaplarından gelen formülleri kodla karşılaştırmayı çok daha kolaylaştırır.

Optiğe aşina olan herkes derhal Rin gibi bir şeyi iç yarıçap olarak (bir fizik belgesinde, inbir abonelik haline getirilir), dış yarıçapı gibi Rout'u vb. Tanıyacaktır. innerRadiusdaha bilinen terminolojilere benziyorsa , bunu yapmak kodu o kişiye daha az açık hale getirecektir. Tanıdık bir formülün yanlış kodlandığı durumları tespit etmek zorlaşacak ve bir yazıda veya ders kitabında bulabilecekleri denklemlere kodlu denklemleri çevirmeyi zorlaştıracaktır.

Bu koda bakacak tek kişi sizseniz, asla kodla standart bir optik denklem arasında çeviri yapmanıza gerek yoktur ve gelecekte bir fizikçinin gelecekte koduna bakması gerekmeyebilir. yeniden yapılandırıcıya mantıklı olun, çünkü kısaltmaların yararı artık maliyete ağır basmıyor. Eğer bu yeni bir gelişme olsaydı, literatürde bulacağınız kodda aynı kısaltmaları kullanmak neredeyse kesinlikle mantıklı olurdu.

Kısa ömürlü değişkenler kısaca adlandırılmalıdır. Örnek olarak, sen yazmazsın for(int arrayCounter = 0; arrayCounter < 10; arrayCounter++) { .... Bunun yerine kullanıyorsunuz for(int i ....

Genel kuralda, değişken kapsamı kısaldıkça adın kısa olması gerektiği söylenebilir. Döngü sayaçları genellikle sadece tek harfleri olduğunu söylüyor i, jve k. Yerel değişkenler gibi bir şey vardır baseOr fromve to. Örneğin küresel değişkenler biraz daha ayrıntılı EntityTablePointer.

Belki de böyle bir kural, üzerinde çalıştığınız kod tabanına uymuyor olabilir. Yine de bazı refactoring yapmak için iyi bir sebep!

Koddaki sorun kısa isimler değil, kısaltmaları açıklayabilecek veya değişkenlerin türetildiği formüller hakkında faydalı materyallere işaret edecek bir yorum eksikliğidir.

Kod sadece problemin etki alanına aşinalık olduğunu varsayıyor.

Bu sorun değil, sorunlu alan aşina olması, özellikle kodu "sahip" birinin rolünde, kodu anlamak ve sürdürmek için gerekli olabileceğinden, uzatma adlarını dolaşmaktan ziyade aşinalık edinmenizi sağlar.

Ancak kodun sıçrama tahtası olarak kullanılabilecek bazı ipuçları vermesi iyi olurdu. Bir etki alanı uzmanı bile dKkonik bir sabit olduğunu unutabilir . Bir açıklama bloğuna küçük bir "kopya kağıdı" eklemek, zarar vermez.

Problem alanında iyi bilinen bazı değişkenler için - burada bulunduğunuz gibi - terse değişken isimleri uygundur. Bir oyun üzerinde çalışıyorum, ben oyunumu kişiler pozisyon değişkenleri istiyorum xve ydeğil horizontalPositionve verticalPosition. Endeksleme ötesinde herhangi anlamlara sahip olmamasıdır Aynı şekilde döngü sayaçları, ben görmeyi bekleyebilirsiniz i, j, k.

"Temiz Kod" a göre:

Değişken isimleri:

• Niyeti açığa çıkarmak
• Dezenformasyondan kaçının
• Anlamlı ayrımlar yapın
• Belirgin olun
• Aranabilir ol

İstisnalar, i,j,k,m,ndöngüler için kullanılan atasözleridir .

Değişken isimleri, haklı olarak şikayetçi olun, yukarıdakilerin hiçbirini yapmayın. Bu isimler kötü isimlerdir.

Ayrıca, her yöntemin kısa olması gerektiğinden , kapsam veya türün kullanımda olmadığını belirtmek için öneklerin kullanılması gerekir .

Bu isimler daha iyi:

radius
curvature
conicConstant
innerAperture
outerAperture
innerRadius
outerRadius

Bir yorumcu, bunun uzun değişken adları ile çok karmaşık olacağını söylüyor:

Kısa değişken isimleri de basit değil:

fnZR = (r^2/fnR(1+Math.sqrt((1+k) * (r^2/R^2)))) + a[1]*r^2 + a[1]*r^4 + a[1]*r^6 ...;

Cevabınız sonunda ismini alana kadar uzun isimler ve ara sonuçlardır :

thisNiceThing =  ( thisOKThing / thisGreatThing ) + thisAwsomeThing;

Eski koddaki değişkenleri yeniden adlandırmamanın iki iyi nedeni vardır.

(1) otomatik bir yeniden ateşleme aracı kullanmıyorsanız, böceklerin ortaya çıkma olasılığı yüksektir. Dolayısıyla, "eğer kırık değilse, düzeltmeyin"

(2) neyin değiştiğini görmek imkansız olan mevcut sürümleri geçmiş sürümlerle karşılaştıracaksınız. Bu, kodun gelecekteki bakımını zorlaştıracaktır.

Değişkenleri bu şekilde adlandırmak için iyi bir neden var mı, yoksa karşılaştığım gibi onları daha açıklayıcı adlara güncellemede haklı mıyım?

Daha küçük isimleri kullanmanın nedeni, orijinal programcının onları çalışmayı daha kolay bulmasıdır. Muhtemelen, bunun böyle olacağını bulma ve sahip olduğunuz kişisel tercihlere sahip olmama hakları vardır. Şahsen ben bulurum ...

dDin better than dDinnerAperture
dDout better than dDouterAperture

... eğer onları uzun, karmaşık hesaplamalarda kullanıyor olsaydım. Matematik ifadesi ne kadar küçük olursa, hepsini bir kerede görmek o kadar kolay olur. Durum böyle olsa da, dIn ve dOut kadar iyi olabilirler, bu yüzden kolay bir yazım hatası verebilecek tekrarlayan bir D yoktu.

Öte yandan, çalışmayı zor buluyorsanız, o zaman kendinizi yere sermek ve daha sonra yeniden biçimlendirmek için yeniden adlandırın. Özellikle bu koddan siz sorumlusunuz.

Genel olarak, bunun için kuralın, kendi kodunuzda "teknikte uzman" olan kişilerin, bu değişken adının referansını derhal anlayacağını bildiğiniz son derece kısa değişken isimleri kullanabilmeniz gerektiğine inanıyorum. (Her zaman bu durum haricinde her zaman yorumunuz var) ve değişkenlerin yerelleştirilmiş kullanımlarının nasıl kullanıldığı bağlamına göre kolayca ayırt edilebiliyor.

Bunu genişletmek için, değişken isimlerinizi şaşırtmak için kendi yolunuzdan çıkmamanız gerektiği anlamına gelir, ancak değişken isimleriniz için kısaltmalar kullanabilirsiniz, burada yalnızca kodunuzun altında yatan kavramı anlayan kişilerin muhtemel olduğunu bilirsiniz. Yine de okumak için.

Gerçek bir dünya örneğini kullanmak için, son zamanlarda, enlemde olacak bir Javascript sınıfı oluşturuyordum ve size belirli bir tarihte bekleyeceğiniz güneş ışığı miktarını söyledim.

Bu Sundial sınıfını oluşturmak için belki yarım düzine kaynağa, Astronomi Almanacına ve diğer dillerden (PHP, Java, C vb.) Parçacıklara atıfta bulundum.

Bunların hemen hemen hepsinde, benzer öz kısaltmalar kullandılar, ki bunlar yüzünde mutlak hiçbir şey ifade etmiyordu.

K, T, EPS, deltaPsi, eot, LM,RA

Ancak, fizik bilgisine sahipseniz, ne olduklarını anlayabilirsiniz. Başka birinin bu koda dokunmasını beklemem, o yüzden neden ayrıntılı değişken isimleri kullanıyorsunuz?

julianTime, nutationOfEclipticalLongitudeExpressedInDegrees, equationOfTime, longitudeMean, rightAscension.

Ek olarak, çoğu zaman, değişken isimleri geçici olduğunda, yani, yalnızca geçici olarak bir değer tahsis etmek için kullanılırlar, o zaman, özellikle değişkenin içeriği olduğunda, ayrıntılı bir sürümü kullanmak mantıklı değildir. amacını açıklar.

Kesinlikle var; Çoğu zaman kısa bir değişken adı gerekli olan tek şey.

Benim durumumda, kıdemli Robotik dersimde ara nokta navigasyonu yapıyorum ve robotlarımızı KISS-C'de programlıyoruz. Mevcut ve hedef (x, y) koordinatları, (x, y) mesafeleri, geçerli ve hedef başlıkları ve ayrıca dönüş açıları için değişkenlere ihtiyacımız var.

Özellikle x ve y koordinatları durumunda, uzun değişken bir isim tamamen gereksizdir ve xC (geçerli x), yD (hedef y) ve pD (hedef phi) gibi isimler yeterlidir ve anlaşılması en kolay olanlardır. bu durumda.

Bunların, programcı protokolünün dikte edeceği gibi 'tanımlayıcı değişken isimleri' olmadığını iddia edebilirsiniz, ancak isimler basit bir koda dayandığından (d = destination, c = current), başlangıçta çok basit bir yorum yapıldı. talep ederler.

Değişkenleri bu şekilde adlandırmak için iyi bir neden var mı, yoksa karşılaştığım gibi onları daha açıklayıcı adlara güncellemede haklı mıyım?

Genellikle, karmaşık algoritmalar matlabda (veya benzer bir dilde) uygulanır. Gördüğüm şey insanlar sadece değişken isimlerini devralmak. Bu şekilde uygulamaları karşılaştırmak kolaydır.

Diğer tüm cevaplar neredeyse doğrudur. Bu kısaltmalar, d(örnekte olduğu gibi) başlamadıklarının dışında matematik ve fizikte bulunabilir . D ile başlayan değişkenler genellikle farklılaşmayı temsil edecek şekilde adlandırılır .

Tüm normal kodlama kılavuzları, değişkenleri, adınızı temsil eden ilk harfle (sizin durumunuzdaki gibi) adlandırmamalarını söyler, çünkü tüm modern IDE'lerde koda göz atmak çok kolaydır.

Değişken isimlerinin oldukça kısa olması için bir sebep düşünebilirim.

Kısa isimler, kısa göz açıklığı kullanılarak okunması kolaydır, bu nedenle kısa bir dikkat süresidir.

Örneğin, svdb'nin "veritabanına kaydet" anlamına geldiğine alışınca, kaynak kodu tarama hızı daha da artar çünkü SaveToDatabase (14 karakter, işler daha kötü hale gelirken) yerine hızlıca 4 karakter taramak zorunda kalırım daha karmaşık işlem adları için). Kaynak taramanın büyük bir bölümünü kapladığı için "tarama" "okuma" olmadığını söylüyorum.

Çok miktarda kaynak kodu tararken, bu iyi performans kazanımları sağlayabilir.

Ayrıca, tembel programcının kod yazarken bu kısa isimleri yazmasına yardımcı olur.

Tabii ki, tüm bu "shorthands" kaynak kodunda bazı standart bir yerde listelenmesi bekleniyor.

@Zxcdw'nin söylediklerini biraz farklı bir şekilde çerçevelendirmek ve yaklaşma açısından detaylandırmak için:

Fonksiyonlar saf , kısa ve bazı fonksiyonların mükemmel bir şekilde kapsüllenmesi gerekir: Kara kutu mantığı , 40 yıl boyunca dokunulmamış olmasına bakılmaksızın, tasarlandığı işi yapmaya devam edecektir, çünkü arayüzü (giriş ve çıkış) içsellerinden hiçbir şey bilmemeniz bile ses.

Bu yazmak istediğiniz kod türüdür: bu uzun süren ve taşınması kolay bir koddur.

Gerektiğinde, kodu ince ayarlı tutmak için diğer (satır içi) işlev çağrıları dışındaki işlevleri oluşturun .

Şimdi, uygun bir tanımlayıcı işlev adıyla (gerekirse ayrıntılı!), Bu kısaltılmış değişken adlarının kapsamı çok küçük olduğu için yanlış yorumlanma olasılığını en aza indiririz.

Değişken isimleri, programın okunabilirliğine yardımcı olmak için mümkün olduğunca açıklayıcı olmalıdır. Kendin deneyimledin: programın zayıf adlandırma nedeniyle ne yaptığını tanımlamakta bir sürü sorun yaşadın.

Açıklayıcı ad kullanmamak için iyi bir neden yoktur. Size ve projede çalışan / çalışacak olan herkes yardımcı olacaktır. Aslında kısa isimler için geçerli tek bir geçerli kullanım vardır: loop sayaçları.

Elbette bu ne / yorum için ne?

Ödevler, tanımlayıcı olan yorumlara sahipse, her iki dünyanın da en iyisini elde edersiniz: Değişkenin tanımı ve denklemler, ders kitabı ile kolayca karşılaştırılabilir.

Arabirimler için (örneğin, yöntem imzaları, işlev imzaları) Bunu parametre bildirimlerine açıklama ekleyerek çözme eğilimindeyim. C / C ++ için bu .h dosyasını ve uygulamanın kodunu çözer.

Değişken kullanımının bilinmesinin bağlam ve adlandırmada açık olmadığı durumlarda değişken bildirimleri için de aynısını yaparım. (Bu, aynı zamanda güçlü yazmaya sahip olmayan dillerde de geçerlidir.)

Değişken adını tıkamak istemediğimiz birçok şey var. Açı radyan veya derece mi, hassasiyet veya menzil vb. Bazı toleranslar var mı?

Bu konuda dini değilim. Ben sadece netlikle ilgileniyorum ve şimdi unutkanlık kodumu tekrar ziyaret ettiğimde ne olduğumu anladığımdan emin olmak istiyorum. Ve omzumun üzerinden bakan biri, bir şeyin nerede olduğunu, neyin gerekli olduğunu (uygun bakım için son kritik olan) görmek için bilmeleri gerekenlere sahiptir.

Aşırı kısa değişken isimleri için bir bahane var mı?

İlk olarak: E = MC2 gibi formülleri hesaplarken enerji e için bir değişken adlandırmak aşırı kısa isimlendirme DEĞİLDİR . Sembolleri kısa isimler için argüman olarak kullanmak geçerli değildir.

Bu soru benim için oldukça ilginçti ve sadece bir bahane düşünebiliyorum ve bu para.

Örneğin, dosyanın saniyede birçok kez indirileceğini bilen bir müşteri için javascript kullandığınızı varsayalım . Dosya (bayt sayısıyla) olabildiğince küçükse, daha ucuz olur ve kullanıcıların deneyimini daha iyi hale getirir.

(Sadece örneği 'gerçekçi' tutmak için, daha küçük bir araç kullanmanıza izin verilmedi, neden? Güvenlik sorunları, kod tabanına dokunmak için hiçbir dış araç kullanılamaz.)

Diğer cevapların Macar Notasyonu kullanımından bahsetmediğini fark ettim. Bu, uzunluk tartışmasına diktir, ancak genel olarak isimlendirme şemaları ile ilgilidir.

double dR, dCV, dK, dDin, dDout, dRin, dRout

Tüm bu değişkenlerin başında "d", çift olduklarını belirtmek içindir; ama dil zaten bunu zorluyor. Bu isimlerin netliğine rağmen% 50'ye varan fazlalık !

Hataları azaltmak için bir adlandırma kuralı kullanacaksak , dil tarafından kontrol edilmeyen bilgileri kodlamaktan çok daha iyidir . Örneğin, dK + dRuzunluğa boyutsuz bir sayı eklemek anlamsız olsa da, yukarıdaki kodda hiçbir dilden şikayetçi olmaz .

Bu tür hataları önlemenin iyi bir yolu daha güçlü türler kullanmaktır; Bununla birlikte, eğer çiftleri kullanacaksak, daha uygun bir isimlendirme şeması olabilir:

// Dimensions:
// l  = length
// rl = reciprocal length
double lR, rlCV, K, lDin, lDout, lRin, lRout

Dil hala yazmamıza izin verecek K + lR, ancak şimdi isimler bize bunun yanlış olabileceğine dair bir ipucu veriyor.

Bu Macarca Sistemler (genellikle kötü) ve Uygulamalar Macarca (muhtemelen iyi) arasındaki farktır

http://en.wikipedia.org/wiki/Hungarian_notation

Sadece bir komut var ve (genellikle bir ağ üzerinden) bu script üretilen iş önemli olduğunda illegibly kısa değişken adları, modern yazılım mühendisliğinde kabul edilebilir bir durumdur. O zaman bile, betiği kaynak kontrolünde uzun isimlerle tutun ve betiği yapım aşamasında küçültün .