Macarca Sistemleri'nin cazibesi nedir? [kapalı]

Gelen yönergeleri adlandırma Ne izliyorsun? , yazar diyor ki:

Ayrıca Charles Simonyi Macarca notasyonu kullanarak kodlamayı tercih ediyorum.

Çoğunlukla Petzold / Systems Hungarian lezzetinin Macarca kullanmayı tercih eden birkaç programcıya rastladım. Düşün dwLength = strlen(lpszName).

Yanlış Kod Yanlış Görünüyor Yapma okudum ve Değişken adlarına etki alanı türü bilgilerinin dahil edildiği Apps Macarca için mantığı anlıyorum. Ancak derleyici türünün ismine eklenmesinin değerini anlamıyorum.

Programcılar neden hala bu tarz gösterimi kullanmaya devam ediyor? Sadece atalet mi? Okunabilirliği azaltan herhangi bir fayda var mı? İnsanlar kodu okurken dekoratörleri görmezden gelmeyi öğreniyorlar ve eğer öyleyse nasıl değer katmaya devam ediyorlar?

DÜZENLEME: Geçmişte ya da neden artık geçerli olmadığında birçok yanıt açıklanıyor; bunların her ikisi de alıntıladığım makalede ele alınıyor.

Gerçekten hala kullanan herkesten duymak istiyorum. Neden onu kullanıyorsun? Standartta mı? Gerekli olmasaydı kullanır mıydınız? Yeni bir projede kullanır mısınız? Avantajlar olarak ne görüyorsunuz?

Şu anda Macarcayı tam olarak üç nedenden dolayı kullanıyorum , her şey için akıllıca kaçınıyorum :

1. Bakım yaparken mevcut bir kod tabanıyla tutarlı olmak.
2. Kontroller için, örn. "Kutuları txtFirstName". Genellikle "firstName" değerini ve "firstName" kontrolünü birbirinden ayırmamız gerekir. Macarca bunu yapmak için uygun bir yol sağlar. Tabii ki, "firstNameTextBox" yazabilirim, ama "txtFirstName" anlamak kadar kolay ve daha az karakter. Dahası, Macarca'yı kullanmak, aynı tür denetimlerin bulunmasının kolay olduğu ve genellikle IDE'de ada göre gruplandırıldığı anlamına gelir.
3. İki değişken aynı değere sahip ancak türe göre farklılık gösterdiğinde. Örneğin, gerçekte kullanıcı tarafından yazılan değer için "strValue" ve tamsayıda olduğu gibi ayrıştırıldıktan sonra aynı değer için "intValue".

Fikirlerimi kesinlikle en iyi uygulama olarak ayarlamak istemem, ancak bu kurallara uyuyorum çünkü deneyim bana Macar faydaları kodunun sürdürülebilirliğinin zaman zaman kullanılmasının çok az maliyetli olduğunu söylüyor. Bununla birlikte, kendi pratiğimi sürekli gözden geçiriyorum, bu yüzden fikirlerim geliştikçe farklı bir şey yapabilir.

Güncelleme:

Eric Lippert'in Macarca'nın yanlış kodun yanlış görünmesine nasıl yardımcı olabileceğini açıklayan anlayışlı bir makalesini okudum . Okumaya değer.

Macarca notasyonu kullanmanın büyük bir hayranı değilim ama şu şekilde düşünün:

• Ayrıca, kodunuzda bir TextBox'a işaret eden bir dize bulmanın daha hızlı olduğunu fark edebiliriz: arama kutunuza "txt" yazarak.

Hayır, her öğenin kendi adı olduğu tersi düşünün. Nereye gitmek istediğinizi bulmak sizin için daha yavaş olabilir, değil mi?

Aynı şey bir DropDownList'e başvurmak istediğimizde ddl için de geçerli, daha kolay mı değil mi? :)

İnsanlar bu elementin nerede olduğunu bulmak için fazla zaman harcamazlar.

Önek kullanımı C # gibi modern diller derleyicileri için kullanılamaz, ancak insanlar için kullanılabilir (okunabilir) .

Uygulamalar Macarca (tür sistemi aracılığıyla ifade edilemeyen nesnelerin semantik özelliklerini ifade eden etiketler) 1980'lerin başlarında zayıf yazılan dilleri kullanırken bazı yaygın hatalarla başa çıkmanın makul bir yoluydu. Günümüzün güçlü yazılmış dillerinde çok az amaca hizmet ediyorlar.

Sistem Macarca (bir nesnenin bildirilen türünü gereksiz yere gösteren etiketler), kod tabanına yüzeysel olarak muntazam bir görünüm uygulamak dışında hiçbir amaca hizmet etmemiştir. Apps Hungarian'ın amacını yanlış anlayan ve kod kalitesinin karmaşık kodlama yönergeleri ile artırılabileceğine inanan teknik olmayan yöneticiler ve deneyimsiz programcılar tarafından oluşturuldu ve yayıldı.

Her iki stil de Microsoft'tan kaynaklanmıştır. Bu günlerde Microsoft'un adlandırma kuralları kategorik olarak "Macarca gösterim kullanma" der.

Doğru önek sistemi bulursanız, anahtarlarınızın aşınmasını ve yıpranmasını yayarak yedek klavyelerde harcamayı azaltabilirsiniz.

Sanırım bu konuda genişleyebilirim. SH'yi işyerimde son olarak, ah, on yıl kadar kullandım (çünkü standartlarımızda). Bir sorunun çözülmesine asla yardımcı olmamıştır.

Öte yandan, 'ev kodumda' neredeyse hiç olmadığı kadar süssüz fakat iyi adlandırılmış değişkenler kullandım. SH'yi hiç kaçırmadım.

Her iki yerde de, sabit boyutlu ilkel tipler gerektiren protokol kodu yazdım. Bu, SH için düşünebileceğim en faydalı kullanım durumudur. SH ile yazıldığında söyleyebilmeme yardımcı olmadı ve SH olmadan yazıldığında beni engellemedi.

Sonuç olarak, görebildiğim tek fark klavyenizdeki aşınma ve yıpranma.

Aslında bu ay yazdığım yeni kodda SH kullanmaya başladım.

Ödevim JS'de bazı Perl kodlarının yeniden yazılmasını içeriyordu, böylece web uygulamamızın istemci tarafına taşınabiliyordu. Perl'de SH, genellikle sigils ($ string, @array,% hash) nedeniyle gerekli değildir.

JavaScript'te, SH'nin veri yapılarının türlerini izlemek için çok değerli olduğunu gördüm. Örneğin,

var oRowData = aoTableData[iRow];

Bu, bir tamsayı dizini kullanarak bir nesne dizisinden bir nesneyi alır. Bu sözleşmeye bağlı kalmak veri türlerini araştırmamda epey zaman kazandırdı. Ayrıca, kısa değişken adlarını ( oRowvs. iRow) aşırı yükleyebilirsiniz .

tl; dr: SH, zayıf yazılan bir dilde karmaşık kodunuz olduğunda harika olabilir. Ancak IDE'niz türleri izleyebiliyorsa, bunu tercih edin.

Ayrıca mantığı görmeyi merak ediyorum. Neden geçmişte kullandıklarını biliyoruz: tip bilgisi için IDE desteği eksikliği. Ama şimdi? Basitçe söylemek gerekirse, bunun bir gelenek olduğunu düşünüyorum. C ++ kodu her zaman böyle görünüyordu, neden bazı şeyleri değiştirelim? Ayrıca, Macarca notasyonu kullanan önceki kodun üzerine inşa ettiğinizde, aniden bunu kullanmayı bıraktığınızda oldukça garip görünecektir ...

Systems Hungarian gösterimi aslında biraz can sıkıcıydı, 'tip' terimini yanlış anlamıştı. Sistem geliştiricileri, uygulama etki alanı türünün (satır dizini, sütun dizini, ...) aksine, tam anlamıyla derleyici türü olarak (kelime, bayt, dize, ...) aldı.

Ancak her geliştiricinin, tuzaklara düşmeden önce (tür değiştirme, yeni, anlamlı önekler oluşturma, vb). Bu yüzden sanırım bir atalet var: İyileşmeyen ve neden kötü bir seçim olduğunun farkında olan geliştiricilerden, uygulamayı zorunlu kılan kodlama standartlarına sahip geliştiricilerden ve kullananlardan <windows.h>. Önek notasyonundan kurtulmak için Microsoft'un değiştirmesi çok maliyetli olacaktır (bu birçok yerde yanlıştır: WPARAM?).

İnsanların Macarca'da eksik olduğu bir şey var. Macarca gösterim aslında otomatik tamamlama ile BÜYÜK çalışır.

Diyelim ki bir değişkeniniz var ve ad intHeightOfMonster.

Değişkenin adını unuttuğunuzu varsayalım

YükseklikOfMonster veya MonsterHeight veya MeasurementMonsterHeight olabilir

Bir harf yazabilmek ve otomatik tamamlamanın size bazı değişken adları önerebilmesini istiyorsunuz.

HeightOfMonster'ın bir int olduğunu bilerek, sadece i ve voila yazın.

Zamandan tasarruf.