Macarca gösterim kullanmamaya çabalamak


10

Sistem Macarca için ve aleyhte argümanlar gördüm . Birkaç yıldır her değişkeni isimlendirerek bu sistemi kullanan eski bir proje üzerinde çalışıyorum, değişken türünün bir önekiyle işlev (örn. StrName, intAge, btnSubmit vb.) (Orijinal Macar Apps öneklerini türüne göre biliyorum değişken, tür değil). Bir sonraki projemden tamamen vazgeçmesini istiyorum, ancak benzer şeylere başvurmadan benzersiz bir şekilde adlandırmayı daha zor buluyorum.

Diyelim ki, e-posta adreslerini toplamak ve bunları bir veritabanı tablosunda saklamak için bir web formum var ve adresi db'ye kaydeden işlevi çağıran düğme.

Macarca stil gösterimini kullanıyorsam, kutuyu txtEmaildüğme btnEmailve metin kutusundaki değeri çağırabilirim strEmail. Daha sonra storeEmail(strEmail)e-postayı saklamak için bir işlev kullanabilirim . Burada açık bir kuralım var, her değişkenin ne olduğu belli.

Bu değişkenleri adlandırmak için en iyi uygulama hangisidir?

  • Macar Sistemlerine başvurmadan,
  • onları uzun süre karıştırmadan veya kafa karıştırmadan
  • ve projemin tamamında kullanmak için açık bir kuralla?

2
Benzersiz isimleri bulmakta sorun yaşıyorsanız, diğer adlandırma kurallarınızda veya işlevlerinizin boyutunda yanlış bir şey olabilir.

Hangi teknolojiyi kullanıyorsunuz? Bu öneklerin kendilerini Web Formlarına ödünç verdiği görülüyor.
StuperUser

ASP.NET kullanıyorum (arkasında C # ile)
fearoffours

@delnan - lütfen biraz açıklayabilir misiniz? İşlev boyutu adlandırmayı benzersiz bir şekilde kolaylaştırır?
fearoffours

@fearofours: Daha küçük bir işlevin daha az değişkene ihtiyacı vardır ve daha az değişkenin daha az değişken çakışması olduğu açıktır. Bu, elbette her değişkeni mümkün olan en küçük kapsama koyduğunuzu varsayar.

Yanıtlar:


8

Son noktanız en önemlisidir - ne yaparsanız yapın projenizde ve iş arkadaşlarınızla tutarlı olmanız gerekir. Tutarlılık elde etmenin iki ana yolu vardır ve mümkünse her ikisini de kullanmalısınız. Öncelikle oluşturma sırasında adlandırma kurallarını denetlemek için bir araç kullanın. Net dünyasında StyleCop böyle bir araca iyi bir örnek olacaktır. Tutarlılık elde etmenin ikinci yolu, tüm kodların akran incelemelerine sahip olmaktır, böylece hepiniz bir göz atabilirsiniz.

Diğer iki noktanız bir alternatif soruyor gibi görünüyor. Bir alternatife ihtiyacınız olduğundan emin değilim; Macarların artık popüler olmamaları, yazı sistemi ve araçlar biraz daha az olduğu zaman türün türünün belirlenmesi için kullanılmaya başlanmasıdır. Yani eğer C programlıyorsanız ve işaretçilerden geçip geçmenin tek yolunu türü takip etmek Macarca kullanmaktı. Şimdi, C # veya Java gibi bir dil kullanıyorsanız, işaretçiler (veya çok nadiren) kullanmayacaksınız, bu nedenle her türlü Macarca ihtiyaç ortadan kalkar. Ayrıca, modern IDE'ler, değişkenin üzerine gelerek veya en kötüsü orijinal bildirimi görmek için bazı kısa yollarla türü kolayca görmenizi sağlar. Yani, herhangi bir notasyona ihtiyacınız olduğunu düşünmüyorum, sadece değişkeni yaptığı gibi adlandırın. E-posta adresi ise "e-posta" veya "


2
Form / sayfa / pencere / e-posta için bir düğme, e-posta için bir metin kutusu ve belki de e-posta için başka bir widget / kontrol olduğunda biraz daha zorlaşır ...
FrustratedWithFormsDesigner

7
@FrustratedWithFormsDesigner Her zaman değil. Metin kutusu emailAddressInput olabilir; burada düğme emailAddressSubmit ve dahili sunum basitçe emailAddress olabilir.
Jonathan

@Jonathan: İyi bir noktaya değindin.
FrustratedWithFormsDesigner

3

Web formları / Windows formları / diğer grafiksel öğelerle uğraşırken, birbirine sıkıca bağlanmış kontrollere sahip olabileceğinizden, örneğin bir metin kutusu ve bir araya gelen bir etiket; onları adlandırabilir txtEmailve lblEmailayırt edebilirsiniz. Deneyimlerime göre, bu yaygındır ve aslında yararlıdır.

Ancak arka plan kodunuzda bu tür adlandırma gereksizdir. Bir stringe-postayı saklamak için kullanılan türde bir değişkeniniz varsa , onu adlandırın email. Herhangi bir nedenden dolayı kafanız karışırsa, çoğu IDE bunun üzerine gelmenize ve türünü görmenize izin vermelidir. (İdeal olarak, OO şeylerinde, bir nesnenin niteliği olabilir ve user.Emaildaha da açıktır.)

Kodunuzda haklı olarak adlandırılabilecek bir GUI denetimi olmayan birden fazla nesneniz varsa email, tasarımınızla ilgili bir şeylerin yanlış olduğunu düşünüyorum.


1
Aslında txt ve lbl Macarca değildir, txt sadece kısa fo etiket ve lbl kısa Label için, bir formda tam boy kelimesini kullanmamanız için hiçbir neden yoktur. Macarca, her iki durumda da bir dize olan tür olacaktır.
Steve

1
@Steve Haigh - Hayır, kontrollerin kendilerinden bahsediyorum. TxtEmail adlı "textbox" türünde ve lblEmail adında "label" türünde bir nesneniz var. İkisi de ip değildir. Dize özelliklerine sahip olabilirler , ancak dize değildirler.
Andrew Arnold

1
Ah Üzgünüm. Evet tabi ki. Yine de, EmailTextBox gibi daha açıklayıcı bir ad kullanmamak için hiçbir neden yoktur. VS'nin kötü bir isim üretmesi, onu tutmanız gerektiği anlamına gelmez. Ancak, formlar bağlamında, txt ve lbl kısaltmaları o kadar iyi anlaşılmıştır ki, bu durumda muhtemelen endişelenmeyeceğim.
Steve

3

Değişkeni "uzun süre" yapan nedir?

Yerine txtEmail, btnEmailşunu kullanabilirsiniz UserEmailText, UserEmailButtonve AdminEmailText,AdminEmailButton

Bununla ilgili sorun, değişkenin uzun sürmeye başladığını hissetmeye başlamanızdır:

AdminEmailIsValid değişkenin ne kadar süre kalmasına izin vereceğimi sınırlamaya başlar.

Ayrıca, bir değişken grubunu ve bu değişkenler üzerinde bir dizi işlemi yeniden kullandığınızı fark etmeye başlayabilirsiniz. OOP bunun için tasarlanmıştır . Bir değişken kümesi yerine, genel bir nesne oluşturun:

class EmailForm
  var textBox, button, text
  function storeEmail()

Daha sonra sınıf olarak yeni bir değişken başlatabilir ve verilerinize erişmek için aynı nokta gösterimini kullanabilirsiniz:

userEmailForm = new EmailForm(...data...)
adminEmailForm = new EmailForm(...different data...)
doSomething( userEmailForm.text )
doSomethingElse( adminEmailForm.text )

Tabii ki, bu OOP paradigmasını kullanan dillere yöneliktir, ancak popüler web geliştirme dillerinin çoğu nesne yönelimlidir veya nesne yönelimli koda izin verir (PHP, Python, C #, C ++, Java, JavaScript, ActionScript, vb. ).


TxtEmail UserEmailText avantajı göremiyorum - sadece önek yerine türü son ekliyorsunuz. Yine de "OOP bunun için tasarlandı" gibi.
fearoffours

@fearoffours, OP, benzersiz adlarla ilgili bir sorun yaşadığını itiraf etti, bu örneği iki benzer değişkeni ( UserEmailTextve AdminEmailTextözellikle) ayırt etmenin açıklayıcı bir yolu olarak ekledim . Genellikle ne kadar soyutlama / işlevsellik gerektiğine bağlı olarak kendini bir sınıfa UserEmailText-> UserEmail.text-> taşıma ödünç verdiği için türleri ekler User.email.text.
zzzzBov

Tamam, oradan nereden geldiğini gör. Ek / sınıf karşılaştırması için +1. Oh, ve ben OP!
fearoffours

@fearoffours, lol whoops ...
zzzzBov
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.