Değişken adlarını değişken türlerinin kısaltmasıyla mı eklersiniz? (Macarca Notasyonu) [kapalı]


37

Şu andaki işimde kodlama kuralları yoktur. Herkes hemen hemen istediği gibi kodlar. Şirket küçük olduğu için sorun değil.

Ancak, yeni bir adam son zamanlarda her zaman Macar Notasyonu'nı kullanmayı teklif etti. Şimdiye kadar, bazılarımız bir tür Macar Notasyonu kullandık, bazılarımız kullanmadı. Biliyorsunuz, bu bir mühendislik şirketi, bu yüzden kodlama stilleri algoritmalar sağlam olduğu sürece pek de önemli değil.

Şahsen, bu küçük tip kısaltmaların bir çeşit gereksiz olduğuna inanıyorum. İyi düşünülmüş bir isim genellikle aynı mesajı verir. (Ayrıca, kodumuzun çoğunun bir kavramın zaten olduğu boolveya floatolmadığı bir yerde bulunan garip DSP'ler üzerinde çalışması gerekir ).

Peki Macar Notasyonu hakkında ne düşünüyorsun? Onu kullanır mısın? Neden?



7
Hangi programlama dilini kullanıyorsunuz?
Larry Coleman

3
Aslında bu iyi değil - bir kodlama standardına sahip olmalısınız (resmi ya da başka şekilde), bence asla iyi değil ... ama diğerleri aynı fikirde olmayabilir.
Murph

@Larry: Çoğunlukla C ve C ++ kullanıyoruz, burada ve burada Assembler ve Lua'yı bir saçma ile kullanıyoruz.
bastibe

11
@ Paperflyer, kodlama standartları / kuralları müşteriler için değil, geliştirme ekibi içindir. Aynı geliştiricilerin sonsuza kadar kadroda olacağına inanmıyorsanız (gerçekçi değil), kodlama standartları oluşturmanız ve bunlara uymanız gerektiğine kuvvetle inanıyorum. Daha fazla bakım gerektirebilir sistemlere yol açar, daha hızlı ve daha tutarlı olması için yeni personel üyelerini alır. Olduğu söyleniyor, Macar gösteriminin gereksiz olduğunu ve daha çok geçmişte kaldığını kabul ediyorum. İyi düşünülmüş isimler, özellikle günümüzde kullanılan çok daha güçlü IDE'lerde daha önemlidir.
Mark Freedman

Yanıtlar:


77

Çoğu kişi "Macar Notasyonu" derken aslında " Macarca Sistemler " hakkında konuşuyorlar .

Macarca Sistemler tamamen yararsızdır ve bundan kaçınılmalıdır. Adındaki değişkenin türünü kodlamaya gerek yoktur . Ancak, Macarca Sistemler aslında orijinal "gerçek" Macarca: Uygulamalar Macarca'yı yanlış anlıyor .

Apps Macarca, değişken adı "tür" kodlamak değil, değişken "tür" kodlamak. Öyleyse nWidth, ancak pxWidthveya emWidth("piksel cinsinden genişlik" veya "sırasıyla ems cinsinden genişlik" için). Ancak strNamedeğil sNameveya usName(sırasıyla "güvenli ad" veya "güvenli olmayan ad" için - kullanıcılardan giriş kabul ederken kullanışlıdır: güvenli olmayan dizeler).

Şahsen ben de ikisiyle de sıkılmıyorum. Açıkça bir değerin "türünü" dönüştüren bir şey yapmadığım sürece (örneğin, geçmişte "px" ve "em" önekini kullandım çünkü hataları pxArea = emWidth * emHeightaçıkça görüyoruz ).

Ayrıca Joel'in " Yanlış Kodu Yanlış Görünmesi " başlıklı makalesine bakın .


2
Simonyi'nin konuyla ilgili yazdığı yazıya göz atın: Macarcanın orijinal yapımcısıdır ve versiyonu yararlı olanıdır. msdn.microsoft.com/en-us/library/aa260976(v=vs.60).aspx
Michael Kohne

1
Gerçekten ihtiyacınız varsa, birimleri özel bir türe dahil etmenin bir yolu olmalı (güvenli / güvensiz dizeler için aynı). Bununla birlikte, bunu yaparken performans sorunlarıyla karşılaşabildiğinizi görebiliyorum (örneğin, bir sınıfta bir şamandıra sarmak istemezsiniz). F # 'da, temelde sadece bu amaç için iki katına ilave tip bilgisi ekleyen ölçü birimi özelliğini tanıtır.
Scott Whitlock

1
Kullanıcı girişi ile ilgili kodda, rawörneğin,rawUsername
zzzzBov

1
@Scott başka bir seçenek kesinlikle yazılmış bir typedef olurdu
jk.

1
@JBR: Aslında cevabı okudun mu? "Uygulamalar Macar" olarak, sbir değil için stringfalan ama "güvenli" için (ya da ben de "güvenli dize" duydum).

31

zamiriBaşka bir zarf: Asla fiilBir sıfat kullanHungarca isim Notasyon, edat fiilBelirsizleştirirHerhangi bir zarf doldurunHerhangi bir karşılaştırmalıBloody sıfatHard infinitiveTo verbRead.


6
Beni güldürmeme yardımcı oldu ... sersemletici, ama "için" bir edat, sonsuz değil. "okumak" sonsuzdur.
DrAl

Elbette @ dral, dilbilgisi ucubunun değil mizahi sicilindeydi: D
smirkingman

1
Muhteşemdi, beni güldürürdü. :)
Corv1nus

26

İlk olarak:

Biliyorsunuz, bu bir mühendislik şirketi, bu yüzden kodlama stilleri algoritmalar sağlam olduğu sürece pek de önemli değil.

Kodlama stilleri şirket ne olursa olsun önemlidir. Evet algoritmalar var sesi olmaya, ama kod gerekir herkesin değil, sadece orijinal geliştirici tarafından sürdürülebilir olması. Stil unsurlarını içeren bir kodlama standardına sahip olmak, bunu başarmanın bir yoludur. Tüm kodların tarz olarak aynı olması gerektiğini söylemiyorum - bunun tersine üretken olması gerekir, ancak bir derece tutarlılık olması gerekir.

Şimdi Macar gösterime:

Kullanımlarına rağmen, IntelliSense tipi davranışları destekleyen modern bir IDE ile değişkenin türünü adına dahil etmek gerekli değildir. Bu bilgi sizin için başka şekillerde mevcuttur. Daha kötüsü, gelecekte değişkenin türünü değiştirmeniz gerekirse kodun okunmasını zorlaştırabilir.


21

Kullanmayın. Gereksizdir ve kodu okumayı zorlaştırır.


8
"Gereksiz" den daha kötü. Bazı karmaşık durumlar için doğru olmak zordur. Özellikle, uygulamanızda tanımladığınız sınıfların her birinin bir kısaltmaya ihtiyacı vardır. 20 ya da öylesine sınıfları tanımladıktan sonra, tek harfli kısaltmaların dışındasınız. Şimdi ne var? Bir harfli ve iki harfli bir karışım? Veri yapısının bir elemanına karmaşık referanslar ne olacak? Tamsayılardan dizgelere eşlemelerin harita eşleşmeleri dizisine gösterici? Bunun kısaltması nasıl yardımcı olabilir?
S.Lott

13

(Sistem) Macar Notasyonu ile ilgili tartışmaların çoğu çalışma alanına bağlıdır. Eskiden “hiçbir şekilde!” Tarafına sıkı sıkıya bağlıydım, ancak birkaç yıl boyunca gömülü geliştirme için kullanıldığı bir şirkette çalıştım, bunun bazı avantajlarını bazı uygulamalarda görebiliyorum ve kesinlikle benim üzerimde büyüdü. .

Macarca Sistemleri

Söyleyebileceğim kadarıyla, Sistem Macarca gömülü alanda çok fazla kullanım eğilimindedir. Bilgisayar uygulamalarında, derleyici (örneğin) dizgiler, tam sayılar ve kayan nokta değerleri arasındaki farklarla ilgili birçok konuyla ilgilenecektir. Derinden gömülü bir platformda, daha sık 8-bit işaretsiz tamsayılar, 16-bit işaretli tamsayılar vb. Arasındaki farklardan endişe duyuyorsunuz. Derleyici (hatta MISRA kurallarına uymayan) her zaman bunlardan bahsetmiyor. Değişken adları gibi olan bu durumda u8ReadIndex, s16ADCValueyararlı olabilir.

Macarca Uygulamaları

Uygulamalar Macarca, PC / Web uygulamaları söz konusu olduğunda, örneğin 'güvensiz' dizgeler ile 'güvenli' diziler arasında (yani, bir kullanıcı tarafından girilenler ve kaçtı ya da dahili kaynaklardan okunanlar ya da her ne olursa olsun) olanlar arasında görsel bir fark sunmak gibi belirli avantajlara sahiptir. ). Derleyicinin bu ayrımdan haberi yok.

Amaç ne?

Kullanım (Sistemler veya Uygulamalar) Macarca, yanlış kodun yanlış görünmesi ile ilgilidir .

Güvenli olmayan bir dizeyi, doğrudan çıkmadan güvenli bir dizeye kopyalıyorsanız, Apps Macarca kullanıyorsanız yanlış görünecektir.

İmzalı bir tamsayıyı imzasız bir tamsayı ile çarpıyorsanız, derleyici imzalı olanı imzalı olana (muhtemelen muazzam) imzasız bir numaraya (genellikle sessizce) terfi ettirir, muhtemelen bir hatayla sonuçlanır: Macar Macarca bu durumu yanlış gösteriyor.

Bu durumların her ikisinde de (Uygulamalar / Sistemler) Macar gösterimi, değişken türüne daha az atıfta bulunduğundan, resmi kod incelemelerini daha hızlı yapma eğilimindedir.

Genel olarak, tüm

Genel olarak, benim görüşüme göre en önemli şey bir kodlama standardı olması. Sistem Macarca, Uygulamalar Macarca veya hiç biri kişisel kullanım veya grup tercihi meselesi olsun, girinti türleri seçimi vs. gibi. Ancak, aynı tercihe göre çalışan tüm geliştirme ekibinin kesin avantajları var.


Hangi dillerden bahsettiğinizi açıkça belirtmelisiniz. Gömülü geliştirme ile çalıştığınız için C kullandığınızı varsayıyorum? Macarca C anlamlıdır, ancak daha modern dillerde değildir.
JacquesB

9

Macar Notasyonu'nın amacı, bilgileri tip sisteminde başka türlü kodlanamayan tanıtıcıya kodlamaktır. Benim düşünceme göre, eğer bu bilgiler kodlanacak kadar önemliyse, o zaman doğru bir şekilde kontrol edilebilecek tipte sistemde kodlanacak kadar önemli olduğu. Ve eğer bilgi önemli değilse, neden bu halt ile kaynak kodunuzu karıştırmak istiyorsunuz?

Veya daha özlü bir şekilde söylemek gerekirse: tip bilgisi tip sistemine aittir. (Not: statik tip bir sistem olması gerekmez . Tip hatalarını yakaladığı sürece, onları ne zaman yakaladığı umurumda değildir .)

Macar Notasyonunun kabul edilebilir kullanımları olarak Ölçü Birimlerinden birkaçı daha cevap vermiştir. (NASA'nın Mars İklim Orbiter'ı henüz kimseden bahsetmediğine şaşırdım, çünkü bu, Macar Notasyonu ile ilgili tartışmalarda her zaman ortaya çıktı.

İşte F # 'da basit bir örnek:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

Bak anne, Macar yok!

Ben ise were yerine buraya türleri Macar Notasyonu'nu kullanmak için o bana bir bit yardımcı olmaz:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

Derleyici düz geçmesine izin verdi. Şimdi esasen ne tür bir hata olduğunu anlamak için bir insana güveniyorum . Tip denetleyicisi bunun için değil mi?

Daha da iyisi, Frink programlama dilini kullanarak :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

Yani, özet olarak: Macar Notasyonu'ndan hoşlanmıyorum. Asla kullanmamalısın.

Olduğu söyleniyor, Bence Macar Notasyonu kullanmanın iyi bir fikir olduğunu düşünüyorum. Bir dakika ne?

Evet! Bu özel durumda , bahsettiniz:

Ayrıca, kodumuzun çoğunun bool veya float gibi bir konseptin zaten bulunmadığı bazı garip DSP'ler üzerinde çalışması gerekir.

Ancak bu tam olarak Macar Notasyonu için tek mantıklı kullanım durumudur !


Not: Bütün kalbimle Frink'e bakmanızı tavsiye ederim. Kılavuzu, şimdiye kadarki en harika osuruk şakalarından bazılarını içeriyor. Aynı zamanda oldukça havalı bir dil :-)


Eğer yapabilseydim bunu 50 kere oylardım.
Larry Coleman

1
Çok ilginç tartışma! Bunu şimdiki projemde deneyebilirim. typedef meter float...
bastibe

6

Nesne yönelimli bir dilde bir anlam ifade etmiyor - her şey onu kullanmaya çalışırken görünen bir tür.


6

Macarca Sistemlerin güvence altına alındığı tek yer , C gibi zayıf bir şekilde yazılmış bir dildir. C ile iki kat daha önemlidir, çünkü açık bir nesne yoktur (yapılara sahiptir, ancak tüm işlevler yapı dışındadır). C ++, Java ve C # gibi daha güçlü bir şekilde yazılmış bir şeyde yardımcı olmaz ve aslında işleri daha da kötüleştirir. Kod değişir ve bir türü değiştirmek, değişken adını kullandığınız tüm yerleri değiştirmekten çok daha kolaydır. Ayrıca, göz ardı edilme eğiliminde olan gereksiz bir iş.

Ölçü birimleriniz varsa, bunu bir isimle kodlamaya yardımcı olabilir - ancak sonuçta ekstra gürültü de olabilir. Örneğin, birlikte çalıştığımız farklı şeyler için standart ölçü birimini ilan edeceğiz. Örneğin, gradyan veya derece, metre veya fit, kare veya milisaniye mi kullanıyoruz? Standart kod için ayarlandıktan sonra, bir ölçü biriminde okuduğumuz her zaman, hemen kodun standart ölçü birimine dönüştürürüz.

Tavsiyem : Mevcut ağrı puanlarınızla başlayın ve kodun bu kısmı için makul bir standart seçin. Bir kodlama standardının aşılması, verimsizdir. Değişken ve alan adlarına sahip olduklarını ifade eden çok sayıda değer vardır ve çoğu zaman türü kavramdan güvenle çıkartabilirsiniz.


1
Aslında, iyi IDE'ler (veya eklentiler) genellikle değişken isimlerini kolaylıkla değiştirebilen oldukça güçlü yeniden düzenleme özelliklerine sahiptir.
bastibe

4
Anladım, ancak sürüm değişikliklerinde isim değişikliği için ekstra gürültü de yardımcı olmaz. Diyelim ki katma değer bakımın yükünü haklı göstermiyor.
Berin Loritsch

dile bağlı olarak bazılarının stongly UoM ya da stongly typedefs için doğrudan desteğe sahip olmalarına bağlı olacaktır
jk.

6

HECK NO!

Macar gösterimini veya başka bir gösterimini kullanmayın. Programcılar olarak değişken isimlerimiz için "notasyon" kullanmamalıyız.

Yapmamız gereken değişkenlerimizi iyi adlandırmak :

  • Çok genel isimlerden kaçının. Adını etmeyin zo adlandırılmış nesne, demek, bir telefon faturası temsil eden bir sınıf değişkeni olduğunda. Diyelim phoneBillya PhoneBill.
  • Çok özel isimlerden kaçının. Bir şey ek bilgi olmadan net olduğunda onu içermez. Eğer bir dizgenin karakterleri arasında dolaşmak için sadece bir dizge indeks değişkeni ise ve onu sadece bir kez MyFunc fonksiyonunda kullanırsanız, neden dünyaya neden çağırıyorsunuz MyFuncTempStringCharacterIndex? Bu üzücü bir şaka. Ara Posya da iistersen ara. Bağlamda, bir sonraki programcı ne anlama geldiğini kolayca anlayacaktır.

  • Bir adın ne kadar genel veya özel olması gerektiğine dair bir sıfırlama yaparken, bulunduğu alanı ve diğer olası anlamların bağlamını göz önünde bulundurun. Aynı şekilde kullanılan iki kolay karışmış, benzer tipte öğenin olduğu dar durumda, bu farkı belirtmek için bir önek veya sonek ile gelmek iyidir. Mümkün olduğunca kısa tutun.

Diğer cevaplayıcıların da belirttiği gibi, "Uygulamalar Macarca" yı başlatan, pencereye rwTabPositiongöre ve belgeye göre ölçümler arasında ayrım yapmak için bu dar durumdur rdTabPosition. Ancak, belgeye göre her şeyi yapan bir uygulamada, fazladan hamle eklemeyin! Aslında, neden Jörg W Mittag'ın gerçek bir yeni tür ortaya koyma fikrini kullanmıyorsunuz ? Öyleyse işler karışabilir.

Hemen hemen her alanda, minimum anlam yoğunluğuna sahip şeyler eklemek, genel anlamlılığı ve anlama kolaylığını azaltır. İşte Ben Franklin'den bir örnek . Ve bir başka örnek: İngilizce olarak kelimelerimizi konuşmalarıyla süslemek mümkündür. Daha fazla bilgi değil mi? İngilizceye yeni başlayanların kafası karışırsa, bu onlara gerçekten yardımcı olabilir, değil mi? Bunu okuyun ve bunun uzun vadeli anlama ve bilginin verimli bir şekilde ele alınması için ne kadar faydalı olduğunu söyle:

vrbDo advnot vrbuse nouHungarian nounotation Eklenti nounotation'a eşlik edin. prepupogrammers olarak prepa'lar, vrbs'u, adlandırma adlarını değil, "nounotation" prp'yu nouusing olarak önermeyi önerir.

By ekleyerek bilgiyi, ben tam bir ağrı okumak belirtti.

Bu yüzden notasyonu unut. Her zaman eklediğiniz özel önekleri unutun. Bence buradaki tek gerçek kılavuz şöyle olmalı:

Değişken isimlerini mümkün olduğu kadar kısa , gerektiği kadar anlamlı ve daima açık tutunuz .


Bu neredeyse standartlarımızın tam olarak ne olduğu. Tek fark, harfleri isimlendirmek için kapsayıcı hale getirecek şekilde adlandırırken Pascal Case'i tercih etmemizdir.
DForck42

5

Bir tanımlayıcının amacı, türünden daha önemlidir. Programlarınızdaki tanımlayıcılar için tanımlayıcı adlar kullanıyorsanız, Macar notasyonları kullanmanıza gerek yoktur. isConnectedher zaman daha okunaklı ve anlaşılması kolaydır boolConnected.


2
Kesinlikle katılıyorum! Bu, 'Sistem Macarlığı' yerine 'Uygulama Macarlığı' olarak adlandırdıklarıdır.
bastibe

@bastibe: Hayır, tanımlayıcı isimler dedikleri budur. Uygulamalar Macarca kısaltmalara dayanır.
JacquesB

2

Ben C ++ programcısıyken Macarca kullandık ve harikaydı. Beyanı aramadan bir değişkenin türünü (fe BSTR, CString, LPCTSTR veya char *) görebilirsiniz. O günlerde, bildirimi şu şekilde yaparak ararsınız:

  1. ctrl-ev
  2. CTRL-F
  3. değişken ismi
  4. giriş

Bu yüzden biraz önemli oldu. Fakat 2000 civarında bir yerde, birkaç şey oldu:

  • editörler değişken türünü bir araç ipucu olarak gösterecek kadar akıllı hale geldi
  • editörlerin "bildirime git" kısayolu ve geriye dönmenin hızlı bir yolu vardı
  • C ++ daha az kullanıldı ve diğer birçok dilde daha az değişken türü var. Örneğin, C # 'da, lastNamekesinlikle bir eminiz System.String, çünkü sadece bir string sınıf var.

Macarca uzaklaşan sonlardan biriydim ve şimdi eski kaynak kodunu okuduğumda beni gerçekten sinir ediyor.


2

Sadece Macar gösterimlerinden nefret ediyorum, değişken isimlerini sınırlamak için alt çizgi kullanmayı tercih ediyorum.

Bunun üzerine, yazıyı ilk harf olarak koyduğunuzda, değişken adınızın başlangıcında şöyle: float fvelocity; vect vDirection; string ** ppszWord;

otomatik tamamlama hepsini sıralar ve ne istediğinizi bulma konusunda sorun yaşarsınız ve insanlar daha iyi olduğunu düşündüklerini kullanma eğilimindedir ve artık bir gösterim değildir.

Ben sadece ThingsLikeThat yazmayı seviyorum, değişken hakkında çok tanımlayıcı olmam gerekiyor, çünkü yer tasarrufu sağlıyor ve kapaklar olduğu gerçeği onu daha okunaklı hale getiriyor.

Genelde yaptığım, ilk harfimi Büyük Harf ve değişken isimleri için küçük harfle ve değişken isimleri için alt çizgiyle benim yöntem ve sınıflarımı adlandırmak (bunu sonuncuyu faydalı buluyorum).

Cidden, insanların bu kuralları önemsemesini tercih ederim: Virgül, aritmetik ve ilgili boşluklarla parantez kullanın:

void f(int a, char b);
int a = b + 4 / (3 + 4);

Her satırda en fazla 80 karakter veya AT MOST 90 karakterde, işlevler için uzun veya uzun satırlı argümanlar kullanın if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

1

Çoğu ile aynı fikirdeyim, eski bir tarz.

Modern IDE'lerde, bir değişkenin üzerinde hızlıca gezinme size türü gösterir.


2
Bunu (IDE'nin yardım ettiği) zayıf bir argüman olarak görüyorum - kodlama yaparken, evet, bu kazanca sahip olacaksınız. Ancak, bu desteği sağlayamayacağınız çok sayıda dava vardır (taahhüt, inceleme, fark / suç, vb.).
Murph

Yanlışsın !!!!! ;) Adil nokta, yine de Macarca kullanıcı olmaz!
ozz
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.