क्या सिस्टम हंगेरियन नोटेशन अभी भी एक उपयोगी अभ्यास है? [बन्द है]

Question

मैंने मंच खोजा, लेकिन मुझे जवाब नहीं मिला कि इसे क्यों टाला जाना चाहिए, केवल यह कि यह चांदी की गोली क्यों नहीं है। इसलिए मुझे नहीं लगता कि यह प्रश्न डुप्लिकेट है।

क्या कोई वैध कारण है कि मुझे जिन सिस्टम हंगेरियन का उपयोग करना है, उन्हें अनजान कर देना चाहिए?

अब तक मैं इसका उपयोग करने में निम्नलिखित लाभ देखता हूं:

• लगातार परिवर्तनशील नामकरण
• आप बिना खोज के टाइप करते हैं (समय के आधे समय में अंतर्कलह मृत है / अनुक्रमण है, इसलिए यह अभी भी एक वैध कारण है)
• शब्दार्थ अभी भी नाम के दूसरे भाग में पैक किया जा सकता है

और निम्न डाउनसाइड्स:

• यह कुछ लोगों को परेशान करता है (पता नहीं क्यों)
• यदि प्रकार बदला गया है, तो प्रकार चर के नामकरण से मेल नहीं खा सकता है (मुझे नहीं लगता कि यह वैध कारण है, प्रकार शायद ही कभी बदले जाते हैं, और आपके पास "सभी का नाम बदलें")

तो क्यों:

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

से भी बदतर है:

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?

Comments

अगर इंटेलीजेंस मर चुका है, तो आपका कोड अमान्य है। यदि यह अमान्य है, तो यह क्यों मान लें कि चर नाम सही है?

— बबलपर्व

@Bubblewrap: वैध कोड पर, कभी-कभी 3 सेकंड के लिए अधिकांश अंतर्मुखी कार्यान्वयन दलदल। और कभी-कभी वे काम नहीं करते हैं, भले ही कोड संकलन और लिंक। हम यथोचित आकार की परियोजनाओं के बारे में बात कर रहे हैं।

— कोडर

अपने सुसंगत तर्क के लिए इतना नहीं vectCityNamesहोना चाहिए vectStringCityNames, और यह "प्रश्न" किसी भी चीज़ से अधिक शेख़ी है, आपके पास अपना मन बना हुआ है, इसे बंद कर देना चाहिए।

क्या आप "वैध" कारण मानते हैं?

— एडम लेअर

मुझे नहीं लगता कि आपका दूसरा उदाहरण उस तरह से भ्रमित कर रहा है जिस तरह से आपकी टिप्पणी इंगित करती है। का अर्थ cityNames.push_back(city)बहुत स्पष्ट है। यह शहर के नामों की एक सूची है और आप एक जोड़ रहे हैं।

— क्रिस बर्ट-ब्राउन

Answer 1

मैं इसका इस्तेमाल करता था (कई साल पहले) और मैं अब और नहीं। इसका मुख्य कारण यह है कि मजबूत टाइपिंग (C ++, जावा) के साथ ओओ भाषाओं में मैं बहुत ही कम हूं, जो कि मैंने अपने करियर में सबसे ज्यादा इस्तेमाल किया है। इन भाषाओं में, अगर मैं अपने प्रकारों को अच्छी तरह से परिभाषित करता हूं, तो कंपाइलर मेरे लिए टाइप सेफ्टी को लागू कर सकता है। इसलिए किसी भी नामकरण उपसर्ग केवल अव्यवस्था है जो नाम लंबे समय तक बनाते हैं, इस प्रकार पढ़ना और खोजना कठिन होता है।

किसी भी अच्छी तरह से लिखे गए OO कार्यक्रम में, आपके अधिकांश चर उपयोगकर्ता के प्रकारों के संदर्भ (संदर्भ) हैं। यदि आप इन्हें एक ही सामान्य टैग (जैसे o"ऑब्जेक्ट" के लिए) उपसर्ग करते हैं , तो आपको इसका कोई लाभ नहीं मिलेगा, केवल कमियां। यदि आप उन्हें टाइप-विशिष्ट टैग के साथ उपसर्ग करते हैं, तो आप एक ही तरह के नाम * के साथ एक हजार अलग-अलग प्रकारों के लिए अलग-अलग संक्षिप्ताक्षर खोजने की कोशिश कर रहे हैं, और एक प्रकार या इसका नाम बदलने पर सभी को बदलने के लिए याद रखना (जो है) एक सुव्यवस्थित कार्यक्रम में बिल्कुल भी दुर्लभ नहीं)।

बेशक, यह गैर-ओओ भाषाओं पर लागू नहीं होता है, और यह कमजोर और / या गतिशील रूप से टाइप की गई भाषाओं पर लागू नहीं हो सकता है (सी के अलावा मुझे इनका कोई अनुभव नहीं है)। न तो उपयोग करने योग्य IntelliSense (या इसके स्थानीय समकक्ष) के बिना संपादकों / IDE को उप-करने के लिए। और यह सिर्फ मेरे 2 सेंट है। तो अगर हंगेरियन नोटेशन आपकी टीम और आपके प्रोजेक्ट के लिए काम करता है, तो इसके लिए जाएं। महत्वपूर्ण बात यह है कि परियोजना शुरू होने से पहले इस पर (साथ ही सामान्य रूप से एक सुसंगत कोडिंग शैली पर) सहमति व्यक्त करें और इसे हर समय संगत रखें।

* _{हमारे वर्तमान परियोजना से सिर्फ एक छोटी सूची: हमारे पास है Charge, ChargeBreakdown, ChargeCalculator, ChargeDAO, ChargeDTO, ChargeLineHelper, ChargeMaps, ChargePairऔर ChargeTypeदूसरों के बीच। इसके अलावा हमारे पास Contracts, Countries, Checkouts, Checkins है ... और यह सिर्फ एक अक्षर में सी है, एक परियोजना में जिसे शायद ओपी द्वारा "यथोचित आकार" भी नहीं कहा जाएगा।}

---

अस्वीकरण: मैं वास्तव में एक हंगेरियन हूं, इसलिए मेरा मानना ​​है कि मैं इस मुद्दे पर अधिकार के साथ बात कर सकता हूं ;-)

Comments

"मजबूत टाइपिंग" - यदि C ++ में वास्तव में मजबूत प्रकार की प्रणाली थी, तो आपको चर नाम में हैक के रूप में एम्बेड नहीं करना होगा।

— माइकल बर्ज

@MichaelBurge: यह बात है। आपको नहीं करना है। क्योंकि यह करता है।

— डेडएमजीन

उपयोगकर्ता-परिभाषित प्रकारों के बारे में बात के लिए +1। नामित चर का उपयोग करना iPosया fAmountसहनीय हो सकता है, लेकिन एक कोडबेस पर काम करने का प्रयास करें जहां हर वस्तु चर को एक निरर्थक छह-अक्षर उपसर्ग दिया जाता है जो आपको केवल यह सूचित करता है कि यह "एक संरचना का सूचक" है।

मैं GUI के लिए एक अपवाद बनाऊंगा जहाँ आपको इसके मूल्य के अलावा प्रत्येक नियंत्रण के लिए एक हैंडल को स्टोर करने की आवश्यकता है, इसलिए टेक्स्ट और hText के बजाय प्रवेश बॉक्स के लिए एक अलग नाम के बारे में सोचना होगा। सिस्टम पर विशेष रूप से महत्वपूर्ण है जहां हैंडल सिर्फ एक इंट है, एक विशेष प्रकार नहीं।

— मार्टिन बेकेट

मैं मानना है कि एक प्रमुख जगह है जहाँ जावा हंगेरी संकेतन का उपयोग की सिफारिश की जाना चाहिए था उदाहरण हैं जिनमें उत्परिवर्तित हो सकता है लेकिन कभी भी साझा करने के लिए संदर्भ के बीच अंतर करना है (उदाहरण के लिए char[]एक द्वारा आयोजित StringBuilder), और उदाहरण हैं जिनमें उत्परिवर्तित नहीं किया जा सकता के लिए संदर्भ है, लेकिन (उदाहरण के लिए चीजें हैं जो उन्हें उत्परिवर्तित नहीं होंगे साथ साझा किया जा सकता char[]द्वारा आयोजित String, जो कई के बीच साझा किया जा सकता है Stringउदाहरण)। दोनों क्षेत्र एक ही प्रकार के हैं char[], लेकिन वे चीजें हैं जो बहुत अलग हैं।

— उत्परिवर्तन

Answer 2

क्यों std::vector<string> vecCityNames;बुरा है?

हंगेरियन नोटेशन के साथ समस्या यह है कि आमतौर पर इसका उपयोग किया जाता है, यदि प्रोफाइलिंग से पता चलता है कि शहर के नामों को एक जगह रखा जाना चाहिए, तो std::dequeउस प्रकार की वस्तु का संदर्भ देने वाले सभी चर नाम अचानक एक भ्रामक नाम होंगे।

क्या आप तब अपने सभी चर का नाम बदलने जा रहे हैं? क्या आपने कभी किसी बड़े प्रोजेक्ट में ऐसा करने की कोशिश की है? मर्फी की मदद से (और आदमी अविश्वसनीय रूप से वहां मददगार है) किसी ने कहीं न कहीं चर नामक चीज का इस्तेमाल जरूर किया होगा deqCityNames, जिससे आपके बदलाव बिल्ड को तोड़ते हुए, आपको कोड के साथ घंटों बैठे बैठे छोड़ देंगे, जो कि डेढ़ दशक तक, किसी ने भी देखने की हिम्मत नहीं की। किसी जहरीले जानवर द्वारा काटे जाने के डर से।

हालांकि, मुझे पता है कि चार्ल्स सिमोनी ने हंगरी के साथ जिस तरह से उपसर्ग किया था, उपसर्ग वैचारिक शब्दावलियों का उपयोग कर रहा था , बजाय इसके सिंटैक्टिक प्रकार । यही है, शहर के नामों की आपकी सूची के लिए उचित उपसर्ग, चाहे वह किस प्रकार में लागू किया गया हो, संभवतः होगा listCityNames(या lstCityNames, यदि listआपके लिए पर्याप्त गुप्त नहीं है)।

लेकिन मुझे लगता है कि उपसर्ग काफी सतही है, क्योंकि बहुवचन ("नाम") पहले से ही बताता है कि यह शहरों का एक समूह है। निचला रेखा: जब आप अपने पहचानकर्ताओं को देखभाल के साथ चुनते हैं, तो हंगेरियन संकेतन की शायद ही कभी आवश्यकता होती है। ओटीओएच, जिस तरह से आमतौर पर इसका उपयोग किया जाता है, वह लंबे समय में, वास्तव में कोड को नुकसान पहुंचा रहा है।

Comments

@ कोडर: पूरे प्रोजेक्ट में टाइप का उपयोग किया जाता है, और इस प्रकार के सभी वेरिएबल्स में उपसर्ग होगा। आपको एक वैश्विक चर का नाम नहीं बदलना होगा, लेकिन सैकड़ों स्थानीय लोगों का।

— sbi

आपको जोएल स्पोल्स्की के ब्लॉग पोस्ट में एक लिंक जोड़ना चाहिए जहां वह अपनी व्याख्या प्रस्तुत करता है कि क्यों हंगरी के नोटिफिकेशन के साथ आने के लिए एक चर प्रकार का उपयोग करना गलतफहमी है कि यह सब क्या है। तुम्हारा अच्छा है, लेकिन कुछ लोग कुछ अधिक आधिकारिक की तलाश में हो सकते हैं और आप अपने मामले को वापस लेने के लिए इसका उपयोग कर सकते हैं। joelonsoftware.com/articles/Wrong.html

— शेन वीलटी

@Coder: दुर्भाग्य से, typedefएक गंभीर रूप से कम मूल्यांकन किया उपकरण है

— भारतीय स्टेट बैंक

@ शने: मैंने इस मामले पर अपनी राय लिख दी है। जोएल के साथ फिट होने के लिए ऐसा होना चाहिए, फिर मेरे साथ ठीक है, क्योंकि मैं उनकी राय को महत्व देता हूं, हालांकि मैं उनमें से कुछ से असहमत हूं। लेकिन मुझे दूसरे "प्राधिकारियों" से अपील करने की कोई आवश्यकता नहीं है कि जब वह एक दशक से अधिक कठिन अनुभव के आधार पर अपनी राय रखने के लिए अपील करें। यह अच्छा है कि आपने उस लिंक को पोस्ट किया है, हालांकि, अन्य लोगों की राय को तुलना करने के लिए देखना हमेशा अच्छा होता है।

— sbi

एक लंबे समय से पहले, मैं दुकान के लिए सीवीएस आदमी था, और शीर्ष डेवलपर्स में से एक ने शुरुआती (सेक्स-चेंज सर्जरी आदि) को बदल दिया, और उसके और उसके पहले नामों में एक ही नाम नहीं था)। जब भी उसने किसी फ़ाइल (या एक समान) को छुआ, उसने अपनी सभी आदतों को नए रूप में बदल दिया। मुझे यह बहुत कष्टप्रद लगा, क्योंकि हम ऐतिहासिक विशेषताओं में सभी प्रकार के मामूली बदलाव करेंगे, और यह पता लगाना कठिन था कि वास्तव में क्या बदला गया था और क्यों। बदले vecCityNamesके लिए deqCityNamesकुछ सौ फाइलों में है और आप एक ही बात करते हैं।

— डेविड थॉर्नले

Answer 3

जो भी कारण के लिए, यहां मौजूदा जवाब हंगेरियन संकेतन के लिए औचित्य के आसपास नाचते हुए प्रतीत होते हैं, बिना इसे स्पष्ट रूप से बताए। हंगेरियन नोटेशन प्रकार की जानकारी (एक प्रकार की सैद्धांतिक अर्थ में ) जोड़ने के लिए उपयोगी है जब भाषा में ही ऐसा करना मुश्किल होगा । जैसा कि होता है, यह आमतौर पर सी ++ या जावा के प्रकार के सिस्टम का इस तरह से उपयोग करना मुश्किल नहीं है कि हंगेरियन नोटेशन (जैसा कि आमतौर पर वर्णित है) पूरी तरह से शानदार है, और शायद यही वह है जो इसके खिलाफ बैकलैश का नेतृत्व करता है - यह प्रोग्राम कार्य को जोड़ता है उन सभी एनोटेशन में हमारे एनोटेशन को बनाए रखने के लिए, लेकिन कोई अतिरिक्त मूल्य नहीं देता है (और इससे नुकसान भी हो सकता है, क्योंकि कोड अधिक अव्यवस्थित दिखता है)।

दूसरी ओर, यदि कोई जानकारी टाइप करने के लिए हंगेरियन-नोटेशन के उपयोग को प्रतिबंधित करता है (फिर, एक सैद्धांतिक अर्थ में ) जो नहीं हैस्वाभाविक रूप से भाषा से घिरा हुआ है, तो यह बहुत उपयोगी हो सकता है। उदाहरण के लिए, C और C ++ पॉइंटर पॉइंटर को पॉइंटर टाइप के रूप में पास करते हैं, लेकिन एरे संदर्भ और पॉइंटर्स के अलग-अलग ऑपरेशन होते हैं जिन्हें उनके खिलाफ किया जाना चाहिए: एरे को पहले तत्व से परे इंडेक्स किया जा सकता है, जबकि पॉइंटर्स नहीं होना चाहिए। यह एक उपयोगी जानकारी है जो एक सरणी में एक तर्क के रूप में कार्य करने के लिए पारित होते ही टाइप सिस्टम में खो जाती है। जैसे, हमारे समूह में हमने C और C ++ कोड में चर-नाम एनोटेशन को अपनाया है ताकि यह पता लगाया जा सके कि पॉइंटर चर वास्तव में एकल तत्व का सूचक है, या किसी सरणी के लिए सूचक है। इस कन्वेंशन को अपनाना हमारे कोड बेस में स्मृति भ्रष्टाचार की समस्याओं की घटना में बड़ी कमी के लिए आंशिक रूप से जिम्मेदार है।

Comments

क्या हंगेरियन विफल बना दिया गया था कि इसका अर्थ (WinAPI टीम द्वारा) एक चर के वाक्य रचना प्रकार को सांकेतिक शब्दों में बदलना था , बजाय इसके अर्थ अर्थ के । (थिंक dwबनाम cb।) ऐसा नहीं है कि इसका मूल स्वरूप OO भाषाओं में कम मददगार होगा: एक इंडेक्स अभी भी एक इंडेक्स है, भले ही बिल्ट-इन के बजाय क्लास टाइप में स्टोर किया गया हो।

— sbi

+1 यह बताने के लिए कि यहां वास्तविक तर्क टाइप थ्योरी के बारे में है। हंगेरियन नोटेशन अतिरिक्त जानकारी के साथ टाइप सिस्टम को बढ़ाने के लिए एक तकनीक है, और जैसे कि इसकी सौंदर्य गुणों पर चर्चा होने के बजाय टाइप सिस्टम (उदाहरण के लिए टाइप्डेफ़, आदि) को बढ़ाने के लिए अन्य तकनीकों के साथ तुलना और इसके विपरीत होना चाहिए। उसके अभाव)।

— डैनियल प्रीडन

सवाल विशेष रूप से "सिस्टम हंगेरियन" के बारे में है, घोषित प्रकार का निरर्थक दोहराव, जिसमें कोई अतिरिक्त शब्दार्थ जानकारी नहीं है। मूल वाक्य "हंगेरियन नोटेशन" की मूल भाषा का उपयोग करने का एक मामला हो सकता है, जो कि भाषा सिंटैक्स (सी सहित कुछ भाषाओं में अनुमति दी गई है) से परे जानकारी देने के लिए, हालांकि सी ++ नहीं है जहां आप इसे उपयोगकर्ता-परिभाषित प्रकारों के साथ और अधिक मज़बूती से कर सकते हैं ), लेकिन यह सवाल क्या है के बारे में नहीं है।

— माइक सीमोर

Answer 4

यह कुछ लोगों को परेशान करता है (पता नहीं क्यों)

इसका कारण यह है कि यह मुझे पता है कि यह कोड के मेरे दृश्य स्कैनिंग को धीमा करने वाले हर एक पहचानकर्ता पर थोड़ी गति है। sIt's mAs bIf pYou kHad zTo qRead iEnglish cText lLike uThis।

Answer 5

नफरत बहुत मजबूत शब्द है, IMO। आप किसी भी तरह से अपना कोड लिख सकते हैं; मैं केवल अपने स्वयं के कोड में हंगेरियन नोटेशन का उपयोग नहीं करना पसंद करता हूं, और एक विकल्प देता हूं कि मैं इसे पढ़ने या अन्य लोगों के कोड में इसके साथ काम नहीं करना चाहता हूं।

आपने पूछा कि कुछ लोगों को हंगेरियन नोटेशन कष्टप्रद क्यों लगता है। मैं दूसरों के लिए नहीं बोल सकता, लेकिन इसके कारण जो मुझे गुस्सा दिलाते हैं:

1. यह बदसूरत है। हंगेरियन पूरी तरह से उचित नाम लेता है और एक कोड के लिए क्या मात्रा रखता है। एक बार जब आप इस कोड को आंतरिक कर लेते हैं, तो मुझे यकीन है कि यह सही समझ में आता है, लेकिन बिना किसी सूचना के ऐसा लगता है जैसे किसी ने मेरे स्रोत कोड पर सी ++ नाम के मैंगलर को हटा दिया है।

2. यह बेमानी है। एक चर की घोषणा अपने प्रकार को स्थापित करती है; मुझे उस जानकारी को चर नाम में दोहराने की आवश्यकता महसूस नहीं होती है। यह हर भाषा में सच नहीं है: पर्ल में, उदाहरण के लिए, @ जैसे $ या $ चर नाम से पहले से ही अनिवार्य रूप से चर के प्रकार को परिभाषित करते हैं, इसलिए आपके पास उनका उपयोग करने के अलावा कोई विकल्प नहीं है।

3. यह एक समस्या है जो मेरे पास नहीं है। विधियाँ और कार्य इतने लंबे नहीं होने चाहिए कि आपको स्थानीय वैरिएबल या पैरामीटर की घोषणा को खोजने के लिए कड़ी मेहनत करनी पड़े, और उन्हें इतने अधिक चरों को शामिल न करना पड़े कि आपको क्या हो, इसका ध्यान रखने में परेशानी हो। कोड का उपयोग करने वाले स्थानीय वैरिएबल की घोषणा करना जो उनका उपयोग करता है, इस संबंध में भी मदद करता है। अतीत के सी कंपाइलरों की आवश्यकता है कि सभी स्थानीय चर समारोह की शुरुआत में घोषित किए जाते हैं, लेकिन उस सीमा को बहुत पहले हटा दिया गया था।

4. यह अधूरा है। हंगेरियन नोटेशन का आविष्कार एक ऐसी भाषा (बीसीपीएल) के लिए किया गया था, जिसमें एक प्रकार की प्रणाली नहीं थी, और बाद में एक भाषा (सी) में व्यापक रूप से उपयोग की गई थी जिसमें देशी प्रकारों की संख्या काफी सीमित थी। IMO, यह C ++ या Java जैसी भाषाओं के साथ अच्छी तरह से काम नहीं करता है जिनमें व्यापक प्रकार की प्रणालियाँ हैं। मैं एक चर का प्रकार इंगित करने के लिए एक उपसर्ग का उपयोग क्यों करना चाहूंगा जो कि एक देशी प्रकार है, जैसे कि char [], लेकिन एक वर्ग नहीं है? वैकल्पिक रूप से, यदि मैं vecकक्षाओं के लिए उपसर्गों का आविष्कार करना शुरू करता हूं, तो मैं अपनी कक्षा पदानुक्रम के समानांतर उपसर्गों के एक बड़े पदानुक्रम के साथ समाप्त करूंगा। अगर वह आपको अपील करता है, तो आप उसका स्वागत करते हैं; बस इसके बारे में सोचना मुझे सिरदर्द दे रहा है।

5. यह अस्पष्ट है , कम से कम जैसा कि मैं इसे समझता हूं। बीच क्या अंतर है szFooऔर pszFoo? पहला एक शून्य समाप्त स्ट्रिंग है, और दूसरा शून्य समाप्त स्ट्रिंग के लिए एक संकेतक है। लेकिन सी या सी ++ में, जहां तक ​​मुझे पता है, कोई भी स्ट्रिंग चर प्रभावी रूप से एक सूचक है, इसलिए वे समान हैं या नहीं? मुझे कौन सा उपयोग करना चाहिए? वास्तविक उत्तर वास्तव में मायने नहीं रखता है - मुद्दा यह है कि मैं इस प्रश्न के इन प्रकारों से बचने में मदद करने के लिए बहुत ही अंकन का उपयोग करके उत्तर को नहीं बता सकता। दूसरी ओर, चर की घोषणा को अस्पष्ट होना चाहिए क्योंकि यह वह है जो संकलक उपयोग करता है।

वे चीजें हैं जो मुझे हंगेरियन नोटेशन के बारे में परेशान करती हैं। एक समूह के रूप में भी, हालांकि, मुझे नहीं लगता कि वे पूरी तरह से समझाते हैं कि हंगेरियन को क्यों छोड़ दिया गया है। यहां तीन सबसे बड़े कारण हैं जो अधिकांश प्रोग्रामर हंगरी का उपयोग नहीं करते हैं:

1. इसका उपयोग करने के लिए कोई सम्मोहक कारण नहीं है। उपरोक्त आइटम 3 और 4 देखें। मैं शायद झुंझलाहट के साथ रह सकता हूं अगर हंगेरियन ने हंगेरियन का उपयोग न करने पर कुछ बड़ा लाभ दिया, लेकिन मैं एक नहीं देखता हूं, और जाहिर तौर पर अधिकांश अन्य लोग भी नहीं करते हैं। शायद हंगेरियन के बारे में सबसे अच्छी बात यह थी कि यह एक व्यापक रूप से इस्तेमाल किया जाने वाला सम्मेलन था, और यदि आप मानक उपयोग से चिपके रहते हैं तो आप समान कौशल वाले अन्य प्रोग्रामर से अपेक्षा की जा सकती हैं कि वे संकेतन को समझने में सक्षम हों।

2. उन कंपनियों का प्रभाव बढ़ा जो Microsoft नहीं हैं। यह कहना शायद उचित होगा कि हंगेरियन नोटेशन को अपनाने वाले अधिकांश प्रोग्रामर्स ने ऐसा इसलिए किया क्योंकि माइक्रोसॉफ्ट ने कोड लिखा था, और इसके प्रवाह के साथ जाने के लिए अक्सर आसान था। Google और Apple जैसी कंपनियों के पास पहले की तुलना में अब बहुत अधिक प्रभाव है, और पहले से कहीं अधिक प्रोग्रामर उन कंपनियों और अन्य लोगों की शैलियों को अपना रहे हैं जो ज्यादातर हंगेरियन से बचते हैं। (यह इंगित करना उचित है कि आप अभी भी कुछ अवशेष देख सकते हैं, उदाहरण के लिए, Google और Apple दोनों अक्सर निरंतर नामों के लिए 'k' उपसर्ग का उपयोग करते हैं।)

3. Microsoft ने खुद ही हंगेरियन को छोड़ दिया है। यदि आप Microsoft के सामान्य नामकरण सम्मेलनों को उसके कोडिंग दिशा-निर्देशों की जांच करते हैं, तो आप पाएंगे कि यह बोल्ड रूप में कहता है: हंगेरियन राशन का उपयोग न करें।

तदनुसार, हंगेरियन संकेतन का उपयोग रोकने का एक वैध कारण है:

हंगेरियन नोटेशन की लोकप्रियता इस बिंदु तक कम हो गई है कि सम्मेलन अब मददगार नहीं है। बहुत कम प्रोग्रामर इन दिनों हंगेरियन का उपयोग करते हैं या यहां तक ​​कि समझते हैं, और यह कन्वेंशन इस जानकारी को बताने के लिए बहुत कम प्रभावी है कि यह माना जाता है। यदि आपको अपनी निजी परियोजनाओं में कोड लिखने का यह एक उपयोगी तरीका लगता है, तो रुकने का कोई कारण नहीं है। हालाँकि, यदि आप एक टीम के हिस्से के रूप में कोड लिख रहे हैं जो हंगेरियन का उपयोग नहीं करता है, तो यह एक सफल संचार रणनीति के बजाय आपके और बाकी टीम के बीच एक दीवार बन सकती है।

Comments

"क्या अंतर है szFooऔर pszFoo"? एक है char*, दूसरे char**, मुझे अंतर बताने के लिए 0,25 सेकेंड लगे। Intellisense के साथ कि हरा करने की कोशिश करें।

— कोडर

@ कोडर, pnFooशायद होगा int*, नहीं int**, तो आपको यह जानना होगा कि szइसका मतलब सूचक भी है। मुझे यकीन है कि हंगेरियन उपसर्गों को सीमित करने वाले प्रकारों की सीमित संख्या के लिए यह एक बड़ी समस्या नहीं है, लेकिन हजारों में किसी भी बड़ी परियोजना परिभाषित प्रकारों में। मैं Intellisense के बारे में नहीं जानता, लेकिन आईडीई ने पिछले 25 वर्षों में लगातार सुधार किया है, और मुझे उम्मीद है कि यह प्रवृत्ति जारी रहेगी।

— कालेब

Answer 6

अब तक मैं इसका उपयोग करने में निम्नलिखित लाभ देखता हूं:

• लगातार परिवर्तनशील नामकरण

यदि मैं द सिम्पसंस के पात्रों के बाद अपने सभी चर नाम देता हूं, तो यह भी संगत है, लेकिन क्या यह एक लाभ है?

• आप बिना खोज के टाइप करते हैं (समय के आधे समय में अंतर्कलह मृत है / अनुक्रमण है, इसलिए यह अभी भी एक वैध कारण है)

यह एकमात्र वैध कारण है, जो एक विशिष्ट उपकरण की कमजोरी पर आधारित है ...

• शब्दार्थ अभी भी नाम के दूसरे भाग में पैक किया जा सकता है

यह एक लाभ नहीं है; आप केवल एक ( बड़े पैमाने पर ) के अभाव का दावा कर रहे हैं ।

Answer 7

IDE तुच्छ रूप से मुझे बताएगा कि जब मैं इस पर माउस करता हूं तो एक चर का प्रकार क्या होता है। तो उस जानकारी को डुप्लिकेट करने के लिए परेशान क्यों? मौलिक रूप से, सिस्टम हंगेरियन नोटेशन DRY का उल्लंघन है, इसके साथ जुड़े सभी नुकसानों के साथ। जब यह जानकारी एक आधुनिक वातावरण में तुच्छ रूप से सुलभ है, तो उस कीमत का भुगतान करने का कोई कारण नहीं है।

अपने आप में संगति एक फायदा नहीं है। प्रकार के साथ उनका नामकरण भी सुसंगत नहीं है। यदि आपके नाम में केवल कुछ चर होते हैं तो आपके पास केवल असंगतता होगी। और दूसरे भाग में शब्दार्थ की पैकिंग बस "ठीक है, यह इतना बुरा नहीं है।", बाकी सभी को शब्दार्थ के लिए पूरे नाम का उपयोग करना है । आपके पास सूचीबद्ध कोई वास्तविक लाभ नहीं है।

Comments

"IDE तुच्छ रूप से मुझे बताएगा कि जब मैं इस पर माउस करता हूं तो एक चर का प्रकार क्या होता है।", नमस्ते दुनिया में, हाँ। बड़ी परियोजनाओं पर मुझे यह सुविधा बेहद अविश्वसनीय / धीमी लगती है। ctrl + space, ctrl + space, ctrl + space, ctrl + space, ctrl + space, no go ...

— कोडर

एक नई IDE प्राप्त करें। या एक SSD, जो अद्भुत काम करता है। या बस कम अनावश्यक हेडर शामिल करें।

— डेडएमजी ऑक्ट

यहां तक ​​कि अगर वैरिएबल का प्रकार दिखाते समय आईडीई बहुत धीमा है, या यदि यह बस ऐसा करने में सक्षम नहीं है, तो तरीकों / कार्यों को छोटा रखा जाना चाहिए, ताकि एक चर की घोषणा कभी भी इसके उपयोग से बहुत दूर न हो।

— केविन पेंको

Answer 8

हंगरी संकेतन के पारंपरिक रूपों के साथ एक और बिंदु यह है कि वे आमतौर पर उपसर्ग होते हैं। यहाँ 2 समस्याएं हैं:

1) एक मानव पाठक आमतौर पर सबसे महत्वपूर्ण जानकारी को सबसे पहले पसंद करेगा, हंगेरियन के अधिकांश रूपों में एन्कोड की गई जानकारी यकीनन नाम से कम महत्व की है।

2) उपसर्ग लेक्सिकल छँटाई को प्रभावित करते हैं, इसलिए यदि उदाहरण के लिए आप इंटरफेस या कक्षाओं को निरूपित करने के लिए एक उपसर्ग का उपयोग करने जा रहे हैं और आपकी आईडीई इनमें से एक क्रमबद्ध सूची प्रदान करती है, तो संबंधित वर्ग / इंटरफेस इस सूची में अलग होने जा रहे हैं।

Answer 9

स्पष्ट रूप से, यह राय से नीचे आता है, इसलिए यहां तथ्यों के साथ काम करना मुश्किल हो रहा है। व्यक्तिगत रूप से, मुझे लगता है कि हंगेरियन संकेतन के लिए तर्क जोरदार-टाइप, ऑब्जेक्ट ओरिएंटेड भाषाओं में थोड़ा पतला चलता है। मेरे अनुभव में, OO एप्लिकेशन कक्षाओं को सुसंगत और संक्षिप्त रखकर जटिलता को संभालते हैं, और यही बात कार्यों के बारे में भी कही जा सकती है। इसका मतलब है कि अन्य सभी चीजें समान हैं, आप के साथ समाप्त होता है:

• अधिक कक्षाएं / प्रकार
• कम करने के तरीके

अब, यदि आप हंगेरियन नोटेशन का उपयोग करना चाहते हैं, तो आपको यह तय करना होगा कि क्या इसे बोर्ड भर में लागू करना है, या इसे केवल कुछ विशेष प्रकार और वर्गों (जैसे कोर लाइब्रेरी क्लासेस) के लिए उपयोग करना है। उत्तरार्द्ध मेरे लिए कोई मतलब नहीं है, और पूर्व "एक हजार अलग-अलग प्रकारों के लिए अलग-अलग संक्षिप्ताक्षर खोजने की कोशिश की भूलभुलैया" की ओर जाता है जो कि Péter Török का जिक्र था। इसका मतलब यह है कि संक्षिप्त नाम सूचियों को बनाए रखने में एक महत्वपूर्ण ओवरहेड है, और आमतौर पर "सुसंगत चर नामकरण" खिड़की से बाहर चला जाता है।

छोटी विधियों के बारे में दूसरे बिंदु का मतलब है कि ज्यादातर मामलों में, आपको यह जांचने के लिए कोड की सैकड़ों पंक्तियों से गुजरना नहीं पड़ रहा है कि चर किस प्रकार का है। चर नामकरण थोड़ा और ध्यान से आपके कुछ अन्य प्रश्नों को खत्म कर देगा - जैसे कि cityNameबनाम city। मुझे उम्मीद है कि cityNameयह फ्लोट नहीं है :)

इस बारे में कि यह लोगों को गुस्सा क्यों दिलाता है - फिर से, यह शायद इसका उपयोग करने के लिए नीचे है या नहीं। लेकिन किसी ऐसे व्यक्ति के रूप में जो इसका उपयोग नहीं करता है, मैं आपको बता सकता हूं कि हंगेरियन नोटेशन का उपयोग मेरी आंखों के लिए कोड के प्रवाह को तोड़ देता है, जिससे इसे जल्दी से पढ़ना मुश्किल हो जाता है। संक्षेप में, मैं यह नहीं कह रहा हूँ कि इसकी कोई योग्यता नहीं है (हालाँकि मैंने इसके कुछ कमियों की चर्चा नहीं की है, रिफैक्टिंग, आदि के संदर्भ में), मैं कह रहा हूँ कि यह प्रयास सार्थक नहीं है, दृढ़ता से टाइप की गई, OO भाषाओं के लिए।

Answer 10

मुझे C ++ के संदर्भ में नहीं पता है, लेकिन जावा / सी # दुनिया में मैं बहुत सार्थक नाम रखना पसंद करूंगा, जो एक डोमेन भाषा या संदर्भ से मुझे strFirstNameबताएंगे कि यह एक स्ट्रिंग है; यह स्पष्ट होना चाहिए कि यह एक स्ट्रिंग है, या बेहतर इरादे को व्यक्त करने के लिए नाम को फिर से भरने की आवश्यकता है। यदि आपको यह जानने के लिए उपसर्ग की आवश्यकता है कि आप किस प्रकार के साथ काम कर रहे हैं, तो मैं तर्क दूंगा कि आपका नामकरण असंगत है, न कि वर्णनात्मक पर्याप्त, या बिल्कुल गलत। आधुनिक भाषाओं में मैं हमेशा लंबे नामों को पसंद करता हूं जो अस्पष्ट या अस्पष्ट नामों की तुलना में कोई अस्पष्टता नहीं छोड़ते हैं।

मेरे द्वारा हंगेरियन का उपयोग करने का एकमात्र समय ASP.NET नियंत्रणों के लिए है, और यह अधिक है इसलिए IA) को वास्तव में CustomerFirstNameTextBoxबनाम की तरह कुछ लंबा टाइप करने की आवश्यकता नहीं है txtCustomerFirstName, और B) इसलिए Intellisense सभी नियंत्रण प्रकारों को सॉर्ट करेगा। मुझे लगता है कि "गंदा" भी कर रहा है, हालांकि, मुझे अभी तक एक बेहतर तरीका नहीं मिला है।

Answer 11

मेह - यह वास्तव में व्यक्तिगत प्राथमिकताओं के बारे में है, कोई फर्क नहीं पड़ता कि कोई भी अपनी पसंद को तर्कसंगत बनाने की कोशिश करता है। मैं व्यक्तिगत रूप से "जब रोम में ..." नियम से जुड़ा हुआ हूं और हंगरी में कोड का उपयोग करता हूं जो विंडोज एपीआई को बहुत कॉल करता है। प्लेटफ़ॉर्म-इंडिपेंडेंट कोड के लिए, मैं C ++ स्टैंडर्ड लाइब्रेरी स्टाइल फॉलो करता हूं।

Answer 12

इस प्रश्न में उत्तर निहित है: कृपया मुझे बताएं कि निम्नलिखित चर का नाम कैसे दिया जाए:

char * nullTerminatedString;
wchar * nullTerminatedWideString;
स्ट्रिंग stlString;
wstring stlWideString;
CString mfcString;
बीटीएस कॉमस्ट्रिंग;
_bstr_t atlString;

इन निरंतर स्ट्रिंग्स में जोड़ें, इनको पॉइंटर और इन पर निरंतर पॉइंटर्स।

Comments

szFoo, wczFoo, strFoo, (w)strFoo, strFoo, bstrFoo,bstrFoo

— सांकेतिक शब्दों में बदलनेवाला

Answer 13

मैं आपके द्वारा वर्णित हंगरी नोटेशन के रूप को दृढ़ता से नापसंद करता हूं। कारण? यह 90% समय का कोई बिंदु नहीं है।

उदाहरण के लिए, एक विरासत परियोजना से थोड़ा सा (समतुल्य सी ++ वास्तव में डेल्फी में लिखा गया) कोड मैं सहने के लिए मजबूर हूं:

pRecords[0]->FooMember=10;

... pRecord एक चर है, यह TRecordList प्रकार का है। TRecordList *pRecords[10];

यह एक वर्ग है जिसमें FooMember नाम का एक orioerty है जो fFooMember को इंगित करता है ... या mFooMember पर निर्भर करता है कि क्या यह "फ़ील्ड" या "सदस्य" है (संकेत: वे एक ही बात हैं)

समस्या का? fFooMemberFooMember_ जैसा कुछ हो सकता है क्योंकि हम इसे FooMember सार्वजनिक संपत्ति के माध्यम से हमेशा एक्सेस करेंगे। pRecords? यह बहुत स्पष्ट है कि यह इस तथ्य से एक संकेतक है कि आप इसे सभी जगह से हटा रहे हैं। TRecordList? जब आप संभवतः एक प्रकार का नाम और उस प्रकार की एक वस्तु को भ्रमित कर सकते हैं? संकलक आप पर चिल्लाएगा, और प्रकार लगभग किसी भी स्थान पर उपयोग किए जाते हैं जो ऑब्जेक्ट हैं (स्थैतिक गुणों / विधियों को छोड़कर)

अब, एक जगह है जहाँ मैं मैरी नोटेशन का उपयोग करता हूँ। यह तब होता है जब बहुत सारे यूआई चर के साथ काम करते हैं जिनका अन्य UI चर या नियमित चर के समान नाम होगा।

उदाहरण के लिए, अगर मेरे पास इस पर आपके पहले नाम के लिए एक फॉर्म था।

मेरे पास FirstNameForm नाम का एक वर्ग है। इसके भीतर, लेबल और टेक्स्टबॉक्स के लिए क्रमशः lblFirstName और txtFirstName। और टेक्स्ट बॉक्स में नाम प्राप्त करने और स्थापित करने के लिए एक सार्वजनिक FirstName गुण।

यह भी FirstNameLabel और FirstNameTextBox का उपयोग करके हल किया जा सकता है, लेकिन मुझे लगता है कि यह टाइप करने के लिए लंबा हो जाता है। खासकर जेंडरड्रॉपडाउन लिस्ट जैसे और कुछ के साथ।

इसलिए मूल रूप से, आयु संकेतन सबसे अच्छा है, व्यवस्थित स्तर पर कष्टप्रद है और सबसे खराब मामला हानिकारक है (जैसा कि अन्य उत्तर रिफैक्टिंग और स्थिरता के साथ समस्याओं के बारे में देते हैं)।