Systems Hungarian notation hala faydalı bir uygulama mı? [kapalı]

Forumu araştırdım, ancak neden kaçınılması gerektiğinin cevabını bulamadım, sadece neden bir gümüş kurşun olmadığını. Bu yüzden bu sorunun bir kopya olduğunu sanmıyorum.

Alıştığım Sistemleri Macarca'yı öğrenmememin VALID nedeni var mı ?

Şimdiye kadar kullanmanın aşağıdaki faydaları görüyorum:

• Tutarlı değişken adlandırma
• Arama yapmadan tür görürsünüz (intellisense zamanın yarısı öldü / indeksliyor, bu yüzden hala geçerli bir neden)
• Anlambilim hala adın ikinci bölümüne paketlenebilir

Ve aşağıdaki olumsuz yanları:

• Bazı insanları rahatsız ediyor (neden olduğunu bilmiyoruz)
• Tür değiştirilirse, tür değişkenin adıyla eşleşmeyebilir (geçerli bir neden olduğunu sanmıyorum, türler nadiren değiştiriliyor ve "tümünü yeniden adlandır" dıştınız)

Peki neden:

vector<string> vecCityNames;
wstring strCity = L"abc";
//more code here
vecCityNames.push_back(strCity);

şundan daha kötü:

vector<string> cityNames;
wstring city = L"abc";
//more code here
cityNames.push_back(city);//Are we pushing back int on a queue? Float on a stack? Something else?

Eskiden (yıllar önce) kullanırdım ve artık kullanmıyorum. Asıl sebep, kariyerimin çoğunu kullandığım OO dillerinde güçlü yazma (C ++, Java) ile gereksiz. Bu dillerde, türlerimi iyi tanımlarsam, derleyici benim için tür güvenliğini uygulayabilir ve uygular. Bu nedenle, herhangi bir adlandırma öneki sadece isimleri daha uzun yapan, dolayısıyla okunması ve aranması zor olan karışıklıktır.

İyi yazılmış herhangi bir OO programında değişkenlerinizin çoğu (kullanıcı referansları) kullanıcı tanımlı türlerdir. Bunları aynı genel etikete sahip önek (örneğino "nesne" için olduğu ) ön eklerseniz, bundan dezavantajları alamazsınız. Bununla birlikte, bunları türe özgü etiketlerle önceden eklerseniz, çoğu kez benzer adlara * sahip binlerce farklı tür için farklı kısaltmalar bulmaya çalışarak ve bir tür veya ad değiştiğinde hepsini değiştirmeyi unutmayın (ki bu bakımlı bir programda hiç de nadir değildir).

Tabii ki, bu OO olmayan diller için geçerli değildir ve zayıf ve / veya dinamik olarak yazılmış diller için geçerli olmayabilir (C dışında, bunlarla ilgili deneyimim yok). Kullanılabilir bir IntelliSense (veya bunun yerel eşdeğeri) olmayan alt editörler / IDE'ler. Ve bu sadece benim 2 kuruş. Bu yüzden, Macar notasyonu ekibiniz ve projeniz için işe yararsa, bunun için gidin. Önemli olan , proje başlamadan önce buna (genel olarak tutarlı bir kodlama tarzında olduğu gibi) hemfikir olmak ve her zaman tutarlı olmasını sağlamaktır.

* _{Mevcut proje sadece kısa liste: Elimizdeki Charge, ChargeBreakdown, ChargeCalculator, ChargeDAO, ChargeDTO, ChargeLineHelper, ChargeMaps, ChargePairve ChargeTypediğerleri. Üstelik aynı zamanda Contracts, Countries, Checkouts, Checkins ... ve bu muhtemelen OP tarafından "makul boyutta" olarak bile adlandırılmayacak bir projede sadece C harfidir.}

Feragatname: Aslında bir Macarım, bu konuda otorite ile konuşabileceğime inanıyorum ;-)

Neden std::vector<string> vecCityNames;kötü

Macar gösterimi ile ilgili problem genellikle kullanıldığı gibi, eğer profilleme şehir isimlerinin bir yerde tutulması gerektiğini gösterirse std::deque, o türden bir nesneye atıfta bulunan tüm değişken isimlerinin aniden yanıltıcı bir isme sahip olacağı anlamına gelir.

Daha sonra tüm değişkenlerinizi yeniden adlandırır mısınız? Bunu daha önce büyük bir projede yapmaya çalıştınız mı? Murphy'nin yardımı ile (ve adam orada inanılmaz derecede yardımcı oluyorsa) bir yerdeki birileri kesinlikle bir şey olarak adlandırılan değişkenleri kullanacak deqCityNames, değişikliklerinizi yapıyı bozmaya zorlayacak, sizi saatlerce bile olsa, kimsenin bile bakmaya cesaret edemediği kodlarla uğraşarak saatlerce oturarak bırakacak zehirli bir canavar tarafından ısırılma korkusuyla.

Bununla birlikte, bildiğim kadarıyla, Charles Simonyi'nin Macarca ile olan yolu, önek, sözdizimsel değil, anlamsal kullanım değişkenlerini gösteriyordu . Olduğunu, şehir adları listenizde için uygun önek, muhtemelen olacaktır, bu uygulanan tip ne olursa olsun (ya eğer şifreli yeterli sizin için değil).listCityNameslstCityNameslist

Ancak bu ön ekin oldukça gereksiz olduğunu düşünüyorum, çünkü çoğul ("adlar") zaten bir kaç şehir olduğunu aktarıyor. Alt satır: Tanımlayıcılarınızı dikkatli seçerken, Macarca notasyona nadiren ihtiyaç duyulur. OTOH, yaygın olarak kullanıldığı şekliyle uzun vadede aslında koda zarar veriyor.

Sebep ne olursa olsun, buradaki mevcut cevaplar Macar gösterimi için gerekçeyi açık bir şekilde belirtmeden dans ediyor gibi görünüyor. Macarca notasyonu, dilin kendisinde bunu yapmak zor olacağı zaman tip bilgisini ( tip teorik anlamda ) eklemek için kullanışlıdır . Olduğu gibi, genellikle C ++ ya da Java'nın tür sistemini, Macar notasyonu (genellikle tanımlandığı gibi) tamamen gereksiz olacak şekilde kullanmak o kadar da zor değildir ve muhtemelen buna karşı tepki göstermemeye neden olan şey budur - programcı çalışması ekler. Bu ek açıklamaları tüm değişken nezaketlerimizde tutmak, ancak çok az ek bir değer sağlar (ve kod daha fazla dağınık göründüğü için zarar bile verebilir).

Öte yandan, eğer bir kişi Macar notasyonunun bilgiyi yazmak için kullanımını kısıtlarsa (yine, bir teorik anlamda ) değildoğal olarak dil tarafından kapsüllenmiş, o zaman çok yararlı olabilir. Örneğin, C ve C ++, dizi referanslarını işaretçi türleri olarak iletir, ancak dizi referansları ve işaretçiler, kendilerine karşı yapılması gereken farklı işlemlere sahiptir: sıralayıcılar ilk öğenin ötesine dizine alınabilir, ancak işaretçiler olmamalıdır. Bu, bir dizi argüman olarak bir işleve iletilir geçmez tip sistemine kaybolan faydalı bilgilerdir. Bu nedenle, grubumuzda, bir işaretçi değişkeninin gerçekte tek bir elemana işaretçi mi, yoksa bir elemana işaretçi mi olduğunu ayırt etmek için C ve C ++ kodunda değişken isim ek açıklamaları kabul ettik. Bu sözleşmeyi kabul etmek, kod tabanımızdaki bellek bozulma sorunlarının ortaya çıkmasındaki büyük düşüşlerden kısmen sorumlu olmuştur.

Bazı insanları rahatsız ediyor (neden olduğunu bilmiyoruz)

Beni rahatsız etmesinin nedeni, kodun görsel olarak taranmasını yavaşlatan her bir tanımlayıcıda küçük bir hızlı çarpma. BUNLARINIZA HAZIRLANMASI GEREKENLER BÜTÜNLEŞTİRMEK

Nefret çok güçlü bir kelime, IMO. Kodunuzu istediğiniz şekilde yazabilirsiniz; Sadece Macarca notasyonu kendi kodumda kullanmamayı tercih ediyorum ve bir seçenek verdiğimde başkalarının kodunda da okumayı ya da çalışmamayı tercih ediyorum.

Bazı insanların neden Macar gösterimini sinir bozucu bulduğunu sordunuz. Başkaları için konuşamam, ama beni sinirlendirmesinin sebepleri:

1. Çirkin Macarca oldukça makul isimler alır ve bir koda ne kadar tutarlar hazırlar. Bu kodu bir kez içselleştirdikten sonra, kesinlikle mükemmel bir anlam ifade ediyor, ancak henüz başlatılmamış olanlara göre biri kaynak kodumdaki C ++ adı yöneticisini serbest bıraktı.

2. Gereksiz. Bir değişkenin bildirimi türünü belirler; Bu bilgiyi değişken isminde tekrar etme gereği duymuyorum. Bu her dilde doğru değildir: örneğin Perl'de, değişken ismine göre önceden hazırlanmış @ veya $ gibi sigiller esas olarak değişkenin tipini tanımlar, bu yüzden onları kullanmaktan başka seçeneğiniz yoktur.

3. Bu benim sahip olmadığım bir sorunu çözüyor. Metodlar ve fonksiyonlar o kadar uzun olmamalı, yerel bir değişken veya parametre bildirimi bulmak için çok zor görünmelisiniz ve ne olduğunu takip etmekte zorlandığınız kadar değişken içermemelidir. Yerel değişkenleri, bunları kullanan koda yakın olarak bildirmek de bu konuda yardımcı olur. Geçmişin C derleyicileri, fonksiyonun başlangıcında tüm yerel değişkenlerin bildirilmesini gerektiriyordu, ancak bu sınırlama uzun zaman önce kaldırılmıştı.

4. Eksik. Macar yazımı, bir tür sistemi olmayan bir dil (BCPL) için icat edildi ve daha sonra oldukça sınırlı sayıda yerel tür içeren bir dilde (C) yaygın olarak kullanıldı. IMO, C ++ veya Java gibi dillerde kapsamlı tip sistemlere sahip çalışmaz. Neden char [] gibi bir yerel tür olan bir değişkenin türünü belirtmek için bir önek kullanmak isteyeyim, ancak bu bir sınıf değil? Alternatif olarak, vecsınıflar için olduğu gibi önekler icat etmeye başlarsam , sınıf hiyerarşime paralel geniş bir önek hiyerarşisi ile bitirdim. Bu size hitap ediyorsa, hoş geldiniz demektir; Sadece düşünmek başımı ağrıtıyor.

5. En azından anladığım kadarıyla belirsiz . Arasındaki fark nedir szFoove pszFoo? Birincisi sıfır sonlandırılmış bir dizedir, ikincisi sıfır sonlandırılmış bir dizeye bir göstericidir. Fakat C veya C ++ 'da bildiğim kadarıyla, herhangi bir string değişkeni etkili bir şekilde işaretçidir, yani onlar aynı mı değil mi? Hangisini kullanmalıyım? Asıl cevap gerçekten önemli değil - mesele şu ki, bu tür sorulardan kaçınmama yardım etmesi gereken sözleri kullanarak cevabı ayırt edemem. Değişkenin bildirimi, diğer taraftan, kesin olmalıdır, çünkü derleyicinin kullandığı şey budur.

Bunlar Macar gösterimi hakkında beni rahatsız eden şeyler . Bir grup olarak bile, Macarların neden büyük ölçüde terk edildiğini tam olarak açıkladıklarını sanmıyorum. Çoğu programcının Macarca kullanmaması için en büyük üç neden:

1. Kullanmak için zorlayıcı bir sebep yok. Yukarıdaki 3 ve 4. maddelere bakınız. Macarca, Macar'ın kullanılmamasına göre büyük avantaj sağladıysa, belki sıkıntılarla yaşayabilirdim, ama birini göremiyorum ve görünüşe göre diğer birçok insan da yok. Belki Macarca hakkında en iyi şey, yaygın olarak kullanılan bir konvansiyondu ve standart kullanıma takılırsanız, benzer becerilere sahip diğer programcıların gösterimi anlayabilmelerini makul bir şekilde bekleyebilirsiniz.

2. Microsoft olmayan şirketlerin artan etkisi. Macar gösterimini benimseyen çoğu programcının Microsoft’un kodunu yazdığı ve akışa devam etmesi genellikle daha kolay olduğu için böyle bir şey yaptığını söylemek muhtemelen doğru olur. Google ve Apple gibi şirketler geçmişte olduğundan çok daha büyük etki alanlarına sahipler ve her zamankinden daha fazla programcı bu şirketlerin ve çoğunlukla Macarca'dan kaçan diğerlerinin stillerini benimsiyorlar. (Hala bazı kalıntıları gördüğünüzü belirtmek adil olur, örneğin hem Google hem de Apple, genellikle sabit adlar için 'k' öneki kullanmaktadır.)

3. Microsoft kendisi Macarcayı terk etti. Microsoft'un Genel Adlandırma Kuralları bölümünü kodlama yönergelerinin bir kısmına bakarsanız, kalın harflerle yazıldığını göreceksiniz: Macar notasyonu kullanmayın.

Buna göre, Macar gösterimini kullanmayı bırakmanın geçerli bir nedeni şudur:

Macar gösteriminin popülaritesi, konvansiyonun artık yararlı olmadığı noktasına kadar azaldı. Bu günlerde çok az sayıda programcı Macarca kullanıyor ve hatta anlıyor ve bu nedenle sözleşme olması gereken bilgileri aktarmada çok daha az etkili. Kendi kişisel projelerinize kod yazmanın yararlı bir yolunu bulursanız, durmanız için çok az neden vardır. Bununla birlikte, Macarca kullanmayan bir ekibin parçası olarak kod yazıyorsanız, başarılı bir iletişim stratejisi yerine siz ve ekibin geri kalanı arasında bir duvar olabilir.

Şimdiye kadar kullanmanın aşağıdaki faydaları görüyorum:

• Tutarlı değişken adlandırma

Bütün değişkenlerimi Simpsonlar'daki karakterlerden sonra isimlendirirsem, bu da tutarlı, fakat bu bir fayda mı?

• Arama yapmadan tür görürsünüz (intellisense zamanın yarısı öldü / indeksliyor, bu yüzden hala geçerli bir neden)

Bu, belirli bir aracın zayıflığına dayanan tek geçerli sebep.

• Anlambilim hala adın ikinci bölümüne paketlenebilir

Bu bir fayda değil; Sadece ( büyük ) bir dezavantajın yokluğunu iddia ediyorsunuz .

IDE trivally bana bir değişkenin ne olduğunu farenin üzerine getirdiğimde söyleyecektir. Öyleyse neden bu bilgiyi çoğaltmak rahatsız ediyor? Temel olarak, Sistemler Macar Notasyonu, onunla ilişkili tüm tuzaklarla birlikte, bir DRY ihlalidir. Bu bilgi modern bir ortamda önemsizce erişilebilir olduğunda, bu bedeli ödemek için hiçbir neden yoktur.

Tutarlılık başlı başına bir avantaj değildir. Bunları türle isimlendirmemek de tutarlıdır. Yalnızca bazı değişkenlerin adlarında türlerinin olması durumunda tutarsızlık olur. Ve anlamayı ikinci bölüme yerleştirmek basitçe "Eh, o kadar da kötü değil" demekle birlikte, herkes anlamını tam anlamıyla kullanır. Listelenen herhangi bir gerçek avantajınız yok.

Geleneksel Macarca notaları içeren bir başka nokta, genellikle ön ekler olmasıdır. Burada iki problem var:

1) Bir insan okuyucusu genel olarak ilk önce en önemli bilgiyi ister, çoğu Macarca formunda kodlanan bilginin ismin kendisinden daha az önemi vardır.

2) Önekler sözlüksel sıralamayı etkiler; örneğin, arayüzleri veya sınıfları belirtmek için bir önek kullanacaksanız ve IDE'niz bunların sınıflandırılmış bir listesini sağlarsa, ilgili sınıflar / arayüzler bu listede ayrılacaklardır.

Açıkçası, bu düşüncelere bağlı, bu yüzden burada gerçeklerle çalışmak zor olacak. Şahsen, argüman bulmak için Macar notasyonu kesinlikle yazılan, nesne yönelimli dilde biraz ince çalışır. Tecrübelerime göre, OO uygulamaları sınıfları tutarlı ve özlü tutarak karmaşıklığı ele alma eğilimindedir ve aynı şey işlevler hakkında da söylenebilir. Bu, diğer tüm şeylerin eşit olduğu anlamına gelir;

• Daha fazla sınıf / tip
• Daha kısa yöntemler

Şimdi, Macar gösterimini kullanmak istiyorsanız, tahtayı tüm uygulamaya mı uygulayacağınıza ya da yalnızca belirli ayrıcalıklı tür ve sınıflarda (çekirdek kütüphane sınıfları gibi) kullanmaya karar vermelisiniz. İkincisi bana bir anlam ifade etmiyor ve ilki, Péter Török'in bahsettiği “bin farklı tipte farklı kısaltmalar bulmaya çalışmak labirentine” yol açıyor. Bu, kısaltma listelerinin korunmasında önemli bir ek yük olduğu anlamına gelir ve genellikle "tutarlı değişken isimlendirme" pencereden dışarı çıkar.

Daha kısa yöntemlerle ilgili ikinci nokta, çoğu durumda, bir değişkenin ne tür olduğunu kontrol etmek için yüzlerce kod satırından geçmek zorunda kalmayacağınız anlamına gelir. Değişkenleri biraz daha dikkatli bir şekilde adlandırmak, diğer sorularınızın bir kısmını ortadan kaldırır - örneğin cityName, sadece city. Umarım bu cityNamebir şamandıra değildir :)

İnsanları neden sinirlendirdiğiyle ilgili olarak - yine, bu muhtemelen alışkın olup olmamasına bağlı. Ancak, alışık olmayan biri olarak, Macar gösteriminin kullanılmasının gözlerimin kod akışını bozduğunu, hızlı okumayı zorlaştırdığını söyleyebilirim. Özetlemek gerekirse, bunun hiçbir önemi olmadığını söylemiyorum (bazı olumsuzluklarını, yeniden yapılanma, vb. Açısından tartışmasam da), gayretle yazılmış OO dilleri için çabanın değersiz olduğunu söylüyorum.

C ++ bağlamında bilmiyorum ama Java / C # dünyasında , bana bir Dize olduğunu söylemekten çok, bir etki alanı dili veya bağlamı ileten anlamlı adlara sahip olmayı tercih ederim strFirstName; bunun bir dize olduğu açık olmalı veya adın daha iyi bir niyet iletmek için yeniden adlandırılması gerekiyor. Eğer varsa gerektiren Çalıştığınız ne tür bilmek bir önek, senin adlandırma tutarsız değil, açıklayıcı yeterli, ya da düpedüz yanlıştır iddia ediyorum. Modern dillerde her zaman belirsiz veya belirsiz isimlerden başka belirsizlik bırakmayan isimleri tercih ederim.

Macarca kullandığım tek zaman ASP.NET kontrolleri içindir ve bu daha da IA.) CustomerFirstNameTextBoxKarşı uzunca bir şey yazmak zorunda değil txtCustomerFirstName. Bunu yaparken bile "kirli" hissediyorum, daha iyi bir yol bulamadım.

Meh - tercihlerini rasyonelleştirmek ne kadar zor olursa olsun, kişisel tercihlerle ilgili. Şahsen "Roma’dayken ..." kuralına sadık kalıyorum ve Macarca’yı Windows API’yı çağıran kodda kullanıyorum. Platformdan bağımsız kod için, C ++ Standard Library stilini takip etme eğilimindeyim.

Bu sorunun cevabı yatıyor: Lütfen aşağıdaki değişkenleri nasıl adlandıracağınızı söyleyin:

char * nullTerminatedString;
wchar * nullTerminatedWideString;
string stlString;
wstring stlWideString;
CString mfcString;
BSTR comString;
_bstr_t atlString;

Bu sabit dizelere ekleyin, bunlara işaretçi ve bunlara sabit işaretçiler.

Açıkladığınız Macar notasyonu şeklini kesinlikle beğenmedim. Sebep? Zamanın% 90'ına hiç hizmet etmiyor.

Örneğin, dayanmak zorunda kaldığım eski bir projeden bir bit (eşdeğer C ++. Aslında Delphi'de yazılmış) kodunu:

pRecords[0]->FooMember=10;

... pRecord bir değişkendir, TRecordList türündedir. TRecordList *pRecords[10];

Bir "alan" veya "üye" olup olmadığına bağlı olarak fFooMember ... veya mFooMember 'i işaret eden FooMember adında bir orioerty'den oluşan bir sınıf (ipucu: aynı şey)

Sorunlar? fFooMemberFooMember_ gibi bir şey olabilir, çünkü FooMember kamu malları aracılığıyla her zaman erişeceğiz. pRecords? Her yerde kurallara aykırı olduğun gerçeğinin bir göstergesi. TRecordList? Bir tür adını ve bu tür bir nesneyi ne zaman karıştırmalısınız? Derleyici size bağırır ve türler nesnelerin olduğu hemen hemen hiçbir yerde kullanılmaz (statik özellikler / yöntemler hariç)

Şimdi, Macar gösterimini kullandığım bir yer var. Bu, diğer UI değişkenleriyle veya normal değişkenlerle aynı adı taşıyan birçok UI değişkeniyle ilgilenirken gerçekleşir.

Örneğin, üzerinde Adınız için bir form varsa.

FirstNameForm adında bir sınıfım olurdu. İçinde, sırasıyla etiket ve metin kutusu için lblFirstName ve txtFirstName. Ve metin kutusuna adı almak ve ayarlamak için ortak bir FirstName özelliği.

Bu, FirstNameLabel ve FirstNameTextBox kullanılarak da çözülebilir, ancak yazması uzun sürüyor. Özellikle GenderDropDownList ve benzeri bir şeyle.

Bu nedenle, temel olarak, macar notasyonu en iyi ihtimalle sistematik düzeyde can sıkıcıdır ve En kötü durum zararlıdır (diğer cevaplar yeniden düzenleme ve tutarlılık ile ilgili problemlerde olduğu gibi).