Neden "Macar Notasyonu" kullanmamalıyım?

Macarcanın neyi kastettiğini biliyorum - bir değişken, parametre veya tür hakkında adının ön eki olarak bilgi vermek. Bazı durumlarda iyi bir fikir gibi görünse de, herkes buna şiddetle karşı çıkıyor. Yararlı bilgilerin verildiğini hissediyorsam, neden mevcut olduğu yere koymayayım?

Ayrıca bakınız: İnsanlar gerçek dünyada Macar adlandırma kurallarını kullanıyor mu?

Çoğu kişi Macar gösterimini yanlış kullanıyor ve yanlış sonuçlar alıyor.

Joel Spolsky tarafından yazılan bu harika makaleyi okuyun: Yanlış Kodu Yanlış Görünüyor .

Kısacası, değişken adlarınızın typeönüne (string) (Systems Hungarian) eklediğiniz Macar Notasyonu kötüdür çünkü faydasızdır.

Değişken adının önüne değişken adının önüne kindeklediğiniz (Joel'in örneğini kullanarak: güvenli dize veya güvenli olmayan dize), yazarının amaçladığı şekliyle Macar Gösterimi , yani Apps Macarca'nın kendi kullanımları vardır ve yine de değerlidir.

vjacarca notasyonun kullanılması v, ncode adjdevriming zorlaştırır.

Joel yanılıyor ve işte nedeni.

Bahsettiği "uygulama" bilgisi tip sisteminde kodlanmalıdır . Güvenli olmayan verileri güvenli veri gerektiren işlevlere geçirmediğinizden emin olmak için değişken adlarını çevirmeye güvenmemelisiniz. Bunu yapmanın imkansız olması için bunu bir tür hatası yapmalısınız. Güvenli olmayan verilerin güvenli olmayan olarak işaretlenmiş bir türü olmalıdır, böylece güvenli bir işleve aktarılamaz. Güvenli olmayandan emniyete dönüştürmek için, bir tür temizleme işlevi ile işlenmesi gerekir.

Joel'in "tür" olarak bahsettiği şeylerin çoğu tür değildir; aslında türler.

Bununla birlikte, çoğu dilde eksik olan şey, bu tür ayrımları zorlayacak kadar etkileyici olan bir tür sistemidir. Örneğin, C bir tür "güçlü typedef" e sahip olsaydı (typedef adı temel türdeki tüm işlemlere sahipti, ancak ona dönüştürülemiyordu), o zaman bu sorunların çoğu ortadan kalkardı. Örneğin, bir std :: string'e dönüştürülemeyen (ve böylece aşırı yük çözümlemesine vb. Katılabilen) strong typedef std::string unsafe_string;yeni bir tür tanıtmak için söyleyebilseydiniz, unsafe_stringo zaman saçma öneklere ihtiyacımız olmazdı.

Dolayısıyla, Macarcanın tip olmayan şeyler için olduğu şeklindeki temel iddia yanlıştır. Tip bilgisi için kullanılıyor. Geleneksel C tipi bilgilerden daha zengin bilgi türü, kesinlikle; nesnelerin amacını belirtmek için bir tür anlamsal detayı kodlayan tür bilgisidir. Ancak bu hala bilgi türü ve uygun çözüm her zaman onu tür sistemine kodlamak olmuştur. Bunu tür sistemine kodlamak, kuralların uygun şekilde onaylanmasını ve uygulanmasını sağlamanın en iyi yoludur. Değişken isimleri hardalı kesmez.

Diğer bir deyişle, amaç "yanlış kodu geliştiriciye yanlış göstermek" olmamalıdır. "Yanlış kodu derleyiciye yanlış göster " olmalıdır.

Bunun kaynak kodunu büyük ölçüde karıştırdığını düşünüyorum.

Ayrıca güçlü yazılmış bir dilde size pek bir şey kazandırmaz. Herhangi bir tür uyumsuzluğu yaparsanız, derleyici size bunu anlatacaktır.

Macar notasyonu sadece dilde mantıklı kullanıcı tanımlı tipler olmadan . Modern bir işlevsel veya OO dilinde, değerin "türü" hakkındaki bilgileri değişken adı yerine veri türü veya sınıfa kodlarsınız.

Birkaç cevap Joels makalesine atıfta bulunur . Bununla birlikte, örneğinin, kullanıcı tanımlı sınıfları (en azından uzun bir süre) desteklemeyen VBScript'te olduğuna dikkat edin. Kullanıcı tanımlı türlere sahip bir dilde, bir HtmlEncodedString türü oluşturarak aynı sorunu çözersiniz ve ardından Write yönteminin yalnızca bunu kabul etmesine izin verirsiniz. Statik olarak yazılmış bir dilde, derleyici herhangi bir kodlama hatasını yakalar, dinamik olarak yazıldığında bir çalışma zamanı istisnası alırsınız - ancak her durumda kodlanmamış dizeler yazmaya karşı korunursunuz. Macar notasyonları, programcıyı bir insan tipi denetleyiciye dönüştürür, tipik olarak yazılım tarafından daha iyi işlenen türden bir iştir.

Joel, "Macarca sistemler" ile "macarca uygulamalar" arasında ayrım yapar; burada "sistemler macarca", int, float ve benzeri yerleşik türleri kodlar ve "macarca uygulamalar" "türleri", daha üst düzey meta bilgi kodlar makine türünün dışındaki değişkenler hakkında, Bir OO veya modern işlevsel dilde, kullanıcı tanımlı türler oluşturabilirsiniz, bu nedenle bu anlamda tür ve "tür" arasında bir ayrım yoktur - her ikisi de tür sistemi tarafından temsil edilebilir - ve "uygulamalar" macarca, "sistemler" macarcası kadar fazladır.

Yani sorunuzu cevaplamak için: Sistem Macarcası yalnızca güvenli olmayan, zayıf yazılan bir dilde yararlı olacaktır, örneğin bir int değişkenine bir float değeri atamak sistemi çökertecektir. Macar notasyonu, hiçbir tür denetimi yapmayan oldukça düşük seviyeli bir dil olan BCPL'de kullanılmak üzere altmışlı yıllarda özel olarak icat edildi . Bugün genel olarak kullanılan herhangi bir dilin bu sorunu yaşadığını sanmıyorum, ancak gösterim bir tür kargo kültü programlama olarak yaşandı .

Eski VBScript veya VB'nin ilk sürümleri gibi kullanıcı tanımlı türler olmayan bir dille çalışıyorsanız, Macarca uygulamaları anlamlıdır. Belki de Perl ve PHP'nin erken sürümleri. Yine, onu modern bir dille kullanmak, saf kargo kültüdür.

Başka herhangi bir dilde, Macarca sadece çirkin, gereksiz ve kırılgandır. Tip sisteminden zaten bilinen bilgileri tekrarlar ve kendinizi tekrar etmemelisiniz . Değişken için, türün bu belirli örneğinin amacını açıklayan açıklayıcı bir ad kullanın. Değişmezleri kodlamak için tür sistemini ve değişkenlerin "türleri" veya "sınıfları" hakkındaki meta bilgileri - yani. türleri.

Joels makalesinin genel noktası - yanlış kodun yanlış görünmesi - çok iyi bir ilkedir. Bununla birlikte, hatalara karşı daha da iyi bir koruma - mümkün olduğunda - derleyici tarafından otomatik olarak algılanacak yanlış koda sahip olmaktır.

Tüm projelerim için her zaman Macar notasyonu kullanırım. Yüzlerce farklı tanımlayıcı adıyla uğraşırken bunu gerçekten yararlı buluyorum.

Örneğin, dizge gerektiren bir işlevi çağırdığımda 's' yazıp kontrol alanına basabilirim ve IDE'm bana tam olarak 's' ile başlayan değişken isimlerini gösterecektir.

Diğer bir avantaj, u imzasız ve imzalı girişler için ön ek yaptığımda, potansiyel olarak tehlikeli şekillerde nerede imzalı ve imzasız karıştırdığımı hemen görüyorum.

75000 satırlık devasa bir kod tabanında, yerel değişkenlerin o sınıfın mevcut üye değişkenleriyle aynı şekilde adlandırılmasından dolayı hatalara (ben ve diğerleri tarafından da) kaç kez neden olduğunu hatırlayamıyorum. O zamandan beri üyelerin önüne her zaman 'm_' koyuyorum

Bu bir zevk ve deneyim meselesi. Denemeden vurmayın.

Bu bilgileri eklemenizin bir numaralı nedenini unutuyorsunuz. Seninle hiçbir ilgisi yok, programcı. Şirketten ayrıldıktan 2 veya 3 yıl sonra yoldan aşağı inen ve bunları okumak zorunda olan kişiyle ilgili her şey var.

Evet, bir IDE sizin için türleri hızla belirleyecektir. Bununla birlikte, bazı uzun 'iş kuralları' kodlarını okurken, ne tür olduğunu bulmak için her değişkeni duraklatmak zorunda kalmamak güzeldir. StrUserID, intProduct veya guiProductID gibi şeyler gördüğümde, çok daha kolay ' hızlanma ' süresi sağlıyor.

MS'in bazı adlandırma kurallarında çok ileri gittiğine katılıyorum - bunu "çok fazla iyi bir şey" yığını içinde kategorize ediyorum.

Adlandırma kuralları, onlara bağlı kaldığınız sürece iyi şeylerdir. Yeterince eski koddan geçtim ve bu kadar çok benzer adlandırılmış değişkenin tanımlarına bakmak için sürekli geri döndüm ve "deve kılıfı" (önceki bir işte denildiği gibi) zorladım. Şu anda, VBScript ile binlerce satırlık tamamen yorumlanmamış klasik ASP koduna sahip bir işteyim ve bir şeyleri anlamaya çalışmak bir kabus.

Her değişken adının başındaki şifreli karakterleri işaretlemek gereksizdir ve değişken adının kendi başına yeterince açıklayıcı olmadığını gösterir. Çoğu dil, zaten bildirimde değişken türünü gerektirir, böylece bilgi zaten mevcut olur.

Bakım sırasında bir değişken türünün değişmesi gereken bir durum da vardır. Örnek: "uint_16 u16foo" olarak bildirilen bir değişkenin 64 bitlik işaretsiz olması gerekiyorsa, iki şeyden biri gerçekleşir:

1. Her bir değişken adını gözden geçirecek ve değiştireceksiniz (herhangi bir ilgisiz değişkeni aynı ada sahip olmamasına dikkat ederek) veya
2. Yalnızca türü değiştirin ve adı değiştirmeyin, bu yalnızca kafa karışıklığına neden olur.

Joel Spolsky bununla ilgili güzel bir blog yazısı yazdı. http://www.joelonsoftware.com/articles/Wrong.html Temel olarak, iyi bir IDE hatırlayamıyorsanız değişkeni yazmanızı istediğinizi söyleyeceği zaman kodunuzun okunmasını zorlaştırmamakla ilgilidir. Ayrıca, kodunuzu yeterince bölümlere ayırırsanız, bir değişkenin üç sayfa yukarıda olarak açıklandığını hatırlamanız gerekmez.

Bu günlerde kapsam yazmaktan daha önemli değil, örneğin

* l for local
* a for argument
* m for member
* g for global
* etc

Eski kodu yeniden düzenlemenin modern teknikleriyle, bir sembolün türünü değiştirdiğiniz için arama ve değiştirme sıkıcıdır, derleyici tür değişikliklerini yakalar, ancak çoğu zaman kapsamın yanlış kullanımını yakalamaz, mantıklı adlandırma kuralları burada yardımcı olur.

Macar notasyonunu doğru kullanmamanız için hiçbir neden yok . Popüler olmaması , özellikle Windows API'lerinde, Macar notasyonunun yanlış kullanımına karşı uzun süredir devam eden bir geri tepmeden kaynaklanıyor .

Eski kötü günlerde, DOS için IDE'yi andıran herhangi bir şey olmadan önce (muhtemelen derleyiciyi Windows altında çalıştırmak için yeterli boş belleğiniz yoktu, bu nedenle geliştirmeniz DOS'ta yapıldı), herhangi bir yardım almadınız farenizi bir değişken adının üzerine getirerek. (Fareniz olduğunu varsayarsak.) Uğraşmanız gereken şey, her şeyin size 16-bit int (WORD) veya 32-bit int (LONG WORD) olarak aktarıldığı olay geri çağırma işlevleriydi. Daha sonra bu parametreyi verilen olay türü için uygun türlere çevirmeniz gerekiyordu. Gerçekte, API'nin çoğu neredeyse tipsizdi.

Sonuç, aşağıdaki gibi parametre adlarına sahip bir API:

LRESULT CALLBACK WindowProc(HWND hwnd,
                            UINT uMsg,
                            WPARAM wParam,
                            LPARAM lParam);

WParam ve lParam adlarının oldukça kötü olmasına rağmen, onları param1 ve param2 olarak adlandırmaktan daha kötü olmadığını unutmayın.

Daha da kötüsü, Pencere 3.0 / 3.1'de yakın ve uzak olmak üzere iki tür işaretçi vardı. Dolayısıyla, örneğin, LocalLock bellek yönetimi işlevinin dönüş değeri bir PVOID idi, ancak GlobalLock'un dönüş değeri bir LPVOID idi (uzun süre 'L' ile). Bu berbat gösterim daha sonra genişletildi, böylece basitçe malloc'lu olan bir dizeden ayırmak için, bir l ong p ointer dizgisinin önekine lp getirildi.

Bu tür şeylere karşı bir tepki olması şaşırtıcı değil.

Macar Notasyonu, geliştiricinin belirli değişkenin nasıl kullanıldığını hızlı bir şekilde kendisine hatırlatmasına olanak tanıyacağı için, derleme zamanı tür denetimi olmayan dillerde yararlı olabilir. Performans veya davranış için hiçbir şey yapmaz. Kod okunabilirliğini iyileştirmesi gerekiyor ve çoğunlukla bir zevk ve kodlama tarzı meselesi. Tam da bu nedenle birçok geliştirici tarafından eleştiriliyor - beyinde herkes aynı kablolamaya sahip değil.

Derleme zamanı tür denetleme dilleri için, çoğunlukla yararsızdır - birkaç satır yukarı kaydırıldığında, bildirimi ve dolayısıyla türü ortaya çıkarmak gerekir. Global değişkenleriniz veya kod bloğunuz birden fazla ekrana yayılıyorsa, ciddi tasarım ve yeniden kullanılabilirlik sorunlarınız vardır. Bu nedenle eleştirilerden biri, Macar Notasyonunun geliştiricilerin kötü bir tasarıma sahip olmasına ve bundan kolayca kurtulmasına izin vermesidir. Bu muhtemelen nefretin nedenlerinden biridir.

Öte yandan, derleme zamanı yazım denetimi dillerinin bile Hungarian Notation'dan ( win32 API'deki geçersiz işaretçiler veya HANDLE'lar) yararlanabileceği durumlar olabilir . Bunlar, gerçek veri türünü karıştırır ve orada Macar Gösterimini kullanmanın bir yararı olabilir. Yine de, derleme zamanında veri türü bilebilirse, neden uygun veri türünü kullanmayalım?

Genel olarak, Macar Gösterimini kullanmamak için zor nedenler yoktur. Bu bir beğeniler, politikalar ve kodlama tarzı meselesidir.

Bir Python programcısı olarak Hungarian Notation oldukça hızlı dağılıyor. Python'da, bir şeyin bir dizge olup olmadığı umurumda değil - bir dizge gibi davranıp hareket edemeyeceğini (yani ___str___()bir dizge döndüren bir yöntemi olup olmadığını) önemsiyorum .

Örneğin, diyelim ki bir tamsayı olarak foo, 12

foo = 12

Macar notasyonu bize iFoo ya da onun bir tam sayı olduğunu belirtmek için başka bir şey dememiz gerektiğini söyler, böylece daha sonra ne olduğunu biliriz. Python dışında, bu işe yaramıyor veya daha doğrusu mantıklı değil. Python'da, kullandığım zaman hangi türü istediğime karar veririm. İp ister miyim? peki eğer böyle bir şey yaparsam:

print "The current value of foo is %s" % foo

Not %sdize -. Foo bir dizge değildir, ancak %operatör foo.___str___()sonucu arayacak ve kullanacaktır (var olduğunu varsayarak). foohala bir tamsayıdır, ancak bir dizge istiyorsak onu bir dizge olarak ele alırız. Bir şamandıra istiyorsak, onu bir şamandıra olarak değerlendiririz. Python gibi dinamik olarak yazılmış dillerde, Hungarian Notation anlamsızdır, çünkü kullanana kadar bir şeyin ne tür olduğu önemli değildir ve belirli bir türe ihtiyacınız varsa, o zaman sadece o türe float(foo)çevirdiğinizden emin olun (örn. ) onu kullanın.

PHP gibi dinamik dillerin bu yararı olmadığını unutmayın - PHP, hemen hemen hiç kimsenin ezberlemediği belirsiz bir kurallar dizisine dayanarak arka planda 'doğru şeyi' yapmaya çalışır ve bu da genellikle beklenmedik bir şekilde felaketle sonuçlanan karışıklıklara neden olur. Bu durumda, $files_countveya gibi bir tür adlandırma mekanizması $file_namekullanışlı olabilir.

Benim görüşüme göre, Macar Notasyonu sülükler gibidir. Belki geçmişte yararlıydılar ya da en azından yararlı görünüyorlardı, ancak bugünlerde, pek bir fayda sağlamayan fazladan bir yazı yazmaktır.

IDE bu yararlı bilgileri vermelidir. IDE'ler çok daha az gelişmişken Macarca bir çeşit (çok değil, ama bir çeşit) mantıklı olabilirdi.

Uygulamalar Macarca benim için Yunanca - iyi bir şekilde

Bir programcı değil bir mühendis olarak, hemen Joel'in Google Apps Macarcanın esası hakkındaki makalesine baktım: "Yanlış Kodu Yanlış Görünüyor" . Uygulamalar Macarcayı seviyorum çünkü mühendislik, bilim ve matematiğin denklemleri ve formülleri, alt ve süper yazılmış semboller (Yunan harfleri, matematiksel operatörler vb.) Kullanarak nasıl temsil ettiğini taklit ediyor . Newton'un Evrensel Yerçekimi Yasası'nın belirli bir örneğini ele alalım : önce standart matematiksel gösterimde ve ardından Google Apps Macarca sözde kodunda:

frcGravityEarthMars = G * massEarth * massMars / norm(posEarth - posMars)

Matematiksel gösterimde, en belirgin semboller değişkende depolanan bilgi türünü temsil eden sembollerdir : kuvvet, kütle, konum vektörü, vb. Alt simgeler netleştirmek için ikinci keman oynar: Neyin konumu? Apps Macarcanın yaptığı tam olarak budur; size önce değişkende depolanan türden şeyi söyler ve sonra ayrıntılara girer - en yakın kod matematiksel gösterime ulaşabilir.

Açıkça güçlü yazım, Joel'in denemesindeki güvenli ve güvenli olmayan dizi örneğini çözebilir, ancak konum ve hız vektörleri için ayrı türler tanımlamazsınız; her ikisi de üç boyutlu çift dizilerdir ve birine yapacağınız herhangi bir şey diğerine de uygulanabilir. Dahası, konumu ve hızı birleştirmek (bir durum vektörü yapmak için) veya iç çarpımını almak, ancak muhtemelen bunları eklememek çok mantıklıdır. Yazmak nasıl ilk ikisine izin verir ve ikinciyi yasaklar ve böyle bir sistem korumak isteyebileceğiniz her olası işlemi nasıl kapsar? Yazma sisteminizdeki tüm matematik ve fiziği kodlamaya istekli olmadığınız sürece.

Hepsinden öte, Matlab gibi zayıf yazılmış yüksek seviyeli dillerde veya Fortran 77 veya Ada gibi eski dillerde çok sayıda mühendislik yapılır.

Öyleyse, süslü bir diliniz varsa ve IDE ve Apps Macarca size yardımcı olmuyorsa, unutun - görünüşe göre birçok insan var. Ama benim için, zayıf veya dinamik olarak yazılmış dillerde çalışan acemi bir programcıdan daha kötüsü, Apps Macarca ile, olmadan daha hızlı bir şekilde daha iyi kod yazabilirim.

İnanılmaz derecede fazlalık ve faydasız, en modern IDE'lerdir, burada türü görünür kılmak için iyi bir iş çıkarırlar.

Artı - bana göre - intI, strUserName, vb. Görmek can sıkıcı :)

Yararlı bilgilerin verildiğini hissediyorsam, neden mevcut olduğu yere koymayayım?

O zaman başkalarının ne düşündüğü kimin umurunda? Yararlı bulursanız, gösterimi kullanın.

Ben deneyimim, kötü çünkü:

1 - o zaman bir değişkenin türünü değiştirmeniz gerekirse tüm kodu kırarsınız (yani, 32 bitlik bir tamsayıyı 64 bitlik bir tam sayıya genişletmeniz gerekirse);

2 - tür zaten bildirimde olduğundan veya asıl türün ilk etapta çok önemli olmaması gereken dinamik bir dil kullandığınız için bu gereksiz bilgidir.

Dahası, genel programlamayı kabul eden bir dille (yani, işlevi yazarken bazı değişkenlerin türünün belirlenmediği işlevler) veya dinamik yazım sistemiyle (yani, derleme zamanında tür bile belirlenmediğinde), nasıl adlandırırsınız? değişkenler? Ve çoğu modern dil, kısıtlı bir biçimde olsa bile birini veya diğerini destekler.

In Joel Spolsky en Yapımı Yanlış Kod Bak Yanlış adama ne o herkes (o Sistemleri Macar çağırır) Macar Gösterimi gerçekten (o Uygulamalar Macar dediği) olarak düşünülmüştü sonuç olmaz olarak düşünür olduğunu açıklar. Aşağı kaydırarak I Macaristan olduğum bu tartışmayı görmek için başlığı.

Temel olarak, Systems Hungarian değersizdir. Sadece size derleyicinizin ve / veya IDE'nizin size söyleyeceği şeyi söyler.

Macarca Uygulamaları size değişkenin ne anlama geldiğini söyler ve aslında yararlı olabilir.

Her zaman doğru yerde bir veya iki ön ekin zarar vermeyeceğini düşünmüşümdür. Sanırım, IEnumerable'da olduğu gibi, "Hey, bu bir arayüz, belirli davranışlara güvenme" gibi yararlı bir şey verebilirsem, yapmalıyım. Yorum, bir veya iki karakterli sembolden çok daha fazlasını karıştırabilir.

IDE'nizdeki alfabetik açılır listede denetimlerin listesi görünüyorsa, bir formdaki denetimleri (btnOK, txtLastName vb.) Adlandırmak için yararlı bir kuraldır.

Hungarian Notation'ı yalnızca ASP.NET sunucu denetimleriyle kullanma eğilimindeyim , aksi takdirde formda hangi denetimlerin ne olduğunu bulmayı çok zor buluyorum.

Bu kod parçacığını alın:

<asp:Label ID="lblFirstName" runat="server" Text="First Name" />
<asp:TextBox ID="txtFirstName" runat="server" />
<asp:RequiredFieldValidator ID="rfvFirstName" runat="server" ... />

Eğer birisi Macarca olmadan bu kontrol isimlerine sahip olmanın daha iyi bir yolunu gösterebilirse, ona geçme eğiliminde olurum.

Joel'in makalesi harika, ancak önemli bir noktayı atlıyor gibi görünüyor:

Macarca, kod tabanı genelinde belirli bir 'fikri' (tür + tanımlayıcı adı) benzersiz veya neredeyse benzersiz kılar - çok büyük bir kod tabanı bile.

Bu, kod bakımı için çok büyük. Bu, o 'fikir'den HER ZAMAN bahsetmek için tek satırlık metin aramasını (grep, findstr,' tüm dosyalarda bul ') kullanabileceğiniz anlamına gelir.

Kod okumayı bilen IDE'lerimiz varken bu neden önemlidir? Çünkü henüz bunda pek iyi değiller. Bunu küçük bir kod tabanında görmek zordur, ancak büyük bir kod tabanında açıktır - 'fikir' yorumlarda, XML dosyalarında, Perl komut dosyalarında ve ayrıca kaynak kontrolü dışındaki yerlerde (belgeler, wiki'ler, hata veritabanları) bahsedilebilir.

Burada bile biraz dikkatli olmalısınız - örneğin, C / C ++ makrolarına simge yapıştırmak, tanımlayıcıdan bahsedenleri gizleyebilir. Bu tür durumlar, kodlama kuralları kullanılarak ele alınabilir ve yine de kod tabanındaki tanımlayıcıların yalnızca küçük bir kısmını etkileme eğilimindedirler.

Not: Yazı sistemini kullanmakla ilgili olarak Macarcaya karşı - her ikisini de kullanmak en iyisidir. Derleyici sizin için yakalamazsa, yanlış görünmek için yalnızca yanlış koda ihtiyacınız vardır. Derleyicinin onu yakalamasının mümkün olmadığı birçok durum vardır. Ama mümkünse - evet, lütfen bunun yerine yapın!

Yine de fizibiliteyi değerlendirirken, türleri bölmenin olumsuz etkilerini göz önünde bulundurun. örneğin C # 'da yerleşik olmayan bir türle' int 'sarmalamanın çok büyük sonuçları vardır. Bu nedenle bazı durumlarda mantıklıdır, ancak hepsinde değil.

Macar Notasyonunun yararlarının çürütülmesi

• Değişkenleri ayırt etmenin bir yolunu sağlar.

Tür, bir değeri diğerinden ayıran tek şeyse, o zaman yalnızca bir türün diğerine dönüştürülmesi olabilir. Türler arasında dönüştürülen aynı değere sahipseniz, muhtemelen bunu dönüşüme adanmış bir işlevde yapıyor olmalısınız. (Macar VB6 artıklarının dizeleri tüm yöntem parametrelerinde dizeleri kullandıklarını, çünkü bir JSON nesnesinin nasıl serileştirileceğini çözemedikleri veya boş değer atanabilir türlerin nasıl bildirileceğini veya kullanılacağını doğru bir şekilde anlayamadıklarını gördüm. ) Macarca önek ve bunlar birinden diğerine dönüşüm değil, o zaman onlarla niyetinizi ayrıntılı olarak açıklamanız gerekir.

• Kodu daha okunaklı hale getirir.

Macar gösteriminin insanları değişken isimleriyle tembelleştirdiğini buldum. Onu ayırt edecek bir şeyleri vardır ve amacını detaylandırmaya gerek duymazlar. Bu, tipik olarak Macar notasyonlu kod ve modern: sSQL ile groupSelectSql arasında bulacağınız şeydir ( veya genellikle daha önceki geliştiriciler tarafından yerleştirilen ORM'yi kullanmaları gerektiği için sSQL yoktur ), sValue ve formCollectionValue ( veya genellikle sValue de yoktur, çünkü bunlar MVC'de olurlar ve model bağlama özelliklerini kullanmaları gerekir ), sType vs. publishSource vb.

Okunabilirlik olamaz. Herhangi bir Macar VB6 artığından diğer herkesten daha fazla sTemp1, sTemp2 ... sTempN görüyorum.

• Hataları önler.

Bu yanlış olan 2 sayısı sayesinde olur.

Ustanın sözleriyle:

http://www.joelonsoftware.com/articles/Wrong.html

Her zamanki gibi ilginç bir okuma.

Hulasa:

"Biri, Simonyi'nin" tür "kelimesini kullandığı makalesini bir yerlerde okudu ve bir tür sistemindeki gibi, derleyicinin yaptığı türü kontrol etmek gibi, sınıf gibi yazmayı kastettiğini düşündü. Yapmadı. Çok dikkatli bir şekilde açıkladı. "tip" kelimesiyle tam olarak kastettiği şeyi, ancak yardımcı olmadı. Hasar verildi. "

"Ancak, Google Apps Macarcası için hala muazzam bir değer var, çünkü kodda eşdizimi artırıyor, bu da kodun okunmasını, yazılmasını, hata ayıklamasını ve bakımını kolaylaştırıyor ve en önemlisi yanlış kodu yanlış gösteriyor."

Joel On Software'i okumadan önce biraz zaman ayırdığınızdan emin olun. :)

Birkaç neden:

• Herhangi bir modern IDE, farenizi değişkenin üzerine getirerek size değişken türünü verecektir.
• Çoğu tür adı, makul bir şekilde önek olarak kullanılacak kadar uzun ( HttpClientRequestProvider'ı düşünün ).
• Tür bilgisi doğru bilgiyi taşımaz, değişkenin amacını ana hatlarıyla belirtmek yerine sadece değişken bildirimini başka kelimelerle ifade eder ( myInteger vs. pageSize düşünün ).

Herkesin buna şiddetle karşı olduğunu düşünmüyorum. Statik türleri olmayan dillerde oldukça kullanışlıdır. Tipte olmayan bilgileri vermek için kullanılmasını kesinlikle tercih ederim. C'de olduğu gibi, char * szName değişkenin boş sonlandırılmış bir dizgeye başvuracağını söyler - bu char * içinde örtük değildir - elbette bir typedef de yardımcı olur.

Joel'in, bir değişkenin HTML kodlu olup olmadığını anlamak için Macarca kullanımıyla ilgili harika bir makalesi vardı:

http://www.joelonsoftware.com/articles/Wrong.html

Her neyse, zaten bildiğim bilgileri vermek için kullanılan Macarca'yı sevmiyorum.

Elbette programcıların% 99'u bir konuda hemfikir olduğunda, bir şeyler yanlıştır. Burada hemfikir olmalarının nedeni, çoğunun Macar notasyonunu hiçbir zaman doğru kullanmamış olmasıdır.

Ayrıntılı bir tartışma için sizi konuyla ilgili yaptığım bir blog yazısına yönlendiriyorum.

http://codingthriller.blogspot.com/2007/11/rediscovering-hungarian-notation.html

Hemen hemen Macar notasyonunun icat edildiği ve ilk kez onu bir projede kullanmaya zorlandığım zaman kodlamaya başladım ve ondan nefret ettim.

Bir süre sonra, düzgün yapıldığında gerçekten işe yaradığını fark ettim ve bu günlerde onu seviyorum.

Ama iyi olan her şey gibi, öğrenilmesi ve anlaşılması gerekir ve bunu düzgün bir şekilde yapmak zaman alır.

Macar gösterimi, özellikle Microsoft tarafından kötüye kullanıldı ve değişken adından daha uzun öneklere neden oldu ve özellikle türleri değiştirdiğinizde (Win16'da farklı tür / boyuttaki rezil lparam / wparam, Win32'de aynı) ).

Böylelikle hem bu kötüye kullanım nedeniyle hem de M $ tarafından kullanılması nedeniyle işe yaramaz hale getirildi.

İşimde Java ile kod yazıyoruz, ancak kurucu MFC dünyasından geliyor, bu yüzden benzer kod stili kullanın (hizalanmış parantezler, bunu seviyorum !, büyük harflerle yöntem adlarına, buna alıştım, m_ gibi önek sınıf üyelerine (alanlar ), s_ statik üyelere, vb.).

Ve tüm değişkenlerin türünü gösteren bir ön eke sahip olması gerektiğini söylediler (örn. BufferedReader, brData olarak adlandırılır). Türler değişebildiğinden ancak isimler takip edilmediğinden veya kodlayıcılar bu öneklerin kullanımında tutarlı olmadığından kötü bir fikir olarak gösterilen (Bir Arabellek, Proxy, vb. Bile görüyorum!).

Kişisel olarak, yararlı bulduğum birkaç ön ek seçtim, en önemlisi boole değişkenlerinin önekine b olmaktır, çünkü bunlar sözdizimine izin verdiğim yerlerdir if (bVar)(bazı değerlerin doğru veya yanlış olarak otomatik yayınlanması kullanılmaz). C ile kodladığımda, malloc ile ayrılan değişkenler için bir önek kullandım, daha sonra serbest bırakılması gerektiğini hatırlatmak için. Vb.

Yani, temelde, bu notasyonu bir bütün olarak reddetmiyorum, ancak ihtiyaçlarıma uygun görünen şeyi aldım.
Ve elbette, bir projeye (iş, açık kaynak) katkıda bulunurken, sadece yerinde kuralları kullanıyorum!