मुझे "हंगेरियन नोटेशन" का उपयोग क्यों नहीं करना चाहिए?

Question

मुझे पता है कि हंगेरियन क्या संदर्भित करता है - इसके नाम के लिए उपसर्ग के रूप में एक चर, पैरामीटर या प्रकार के बारे में जानकारी देना। हर कोई इसके खिलाफ भद्दा लगता है, भले ही कुछ मामलों में यह एक अच्छा विचार हो। अगर मुझे लगता है कि उपयोगी जानकारी प्रदान की जा रही है, तो मुझे इसे वहां क्यों नहीं डालना चाहिए जहां यह उपलब्ध है?

यह भी देखें: क्या लोग असली दुनिया में हंगरी के नामकरण सम्मेलनों का उपयोग करते हैं?

Comments

संबंधित: stackoverflow.com/questions/202107/…

— लांस रॉबर्ट्स

Answer 1

अधिकांश लोग हंगेरियन नोटेशन का गलत तरीके से इस्तेमाल करते हैं और गलत परिणाम प्राप्त कर रहे हैं।

जोएल स्पोलस्की का यह उत्कृष्ट लेख पढ़ें: गलत कोड बनाना गलत दिखना ।

संक्षेप में, हंगेरियन नोटेशन जहां आप अपने चर नामों को उनके type(स्ट्रिंग) (सिस्टम हंगेरियन) के साथ जोड़ते हैं, क्योंकि यह बेकार है।

हंगेरियन नोटेशन जैसा कि इसके लेखक का इरादा था जहां आप इसके साथ चर नाम को उपसर्ग करते हैं kind(जोएल के उदाहरण का उपयोग करते हुए: सुरक्षित स्ट्रिंग या असुरक्षित स्ट्रिंग), इसलिए एप्स हंगरी को इसके उपयोग कहते हैं और अभी भी मूल्यवान है।

Comments

अच्छा लिंक, लिंक के पीछे क्या है का एक अच्छा सारांश, और कोई कट्टरता नहीं। अति उत्कृष्ट।

— डस्टमैन

ध्यान दें कि जोल्स उदाहरण VBScript में है, एक ऐसी भाषा जो लंबे समय से उपयोगकर्ता-परिभाषित कक्षाएं नहीं थी। एक OO- भाषा में आप सिर्फ एक HtmlEncodedString-type बनाएँगे और लिखने का तरीका केवल वही स्वीकार करेंगे। "उपयोगकर्ता के प्रकारों के बिना ऐप्स आयुएँ केवल भाषाओं में उपयोगी हैं।

— जैक्सबी

Microsoft को हंगेरियन नोटेशन के पिछले दुरुपयोग के लिए जाना जाता है। पहचानकर्ताओं को पूर्व सूचना टाइप करना न केवल बेकार है, बल्कि यह वास्तव में नुकसान पहुंचा सकता है। सबसे पहले, पठनीयता कम धाराप्रवाह है। दूसरा, ऐसी भाषाओं में जो गलत सूचनाओं का समर्थन करते हुए बहुरूपता या बत्तख टाइप करने में पास हो जाती हैं।

— विल्हेमटेल

मुझे अभी भी हंगेरियन नोटेशन का उपयोग करना पसंद है अगर मैं एक पुराने आईडीई के साथ सीधे सी विकास कर रहा हूं ... इस तरह से मुझे पता है कि कोई टाइपिंग मुद्दे नहीं हैं।

— बीप बीप

@ क्रैमिया: यह आमतौर पर पहली जगह में वर्णनात्मक चर नाम होने से रोका जाएगा। लेकिन अगर आप सुनिश्चित होना चाहते हैं, तो यह लंबाई, भार आदि के लिए अलग-अलग प्रकार (जैसे संरचनाएं) बनाने के लिए अधिक सुरक्षित होगा और यह सुनिश्चित करने के लिए ऑपरेटर ओवरलोडिंग का उपयोग करेगा कि केवल वैध संचालन संभव है।

— जैक्सबी

Answer 2

vUsing adjH ट्वीट्स एनोटेशन vmakes nreading ncode adjdiffific।

Comments

अच्छा सादृश्य, हालांकि थोड़ा अनुचित। तुलना करें: vUsing adjH ट्वीट्स nNotation vMakes nReading nCode adjDifficult।

— क्रिस नू

उस वाक्य में, यूजिंग और रीडिंग दोनों गेरुन्ड हैं। लेकिन मुझे वह बिंदु मिलता है जो आप बना रहे थे ...

— chimp

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

— विल्हेमटेल

@ क्रिस नोए: कुछ पढ़ने की शैलियों (बीच में एक नज़र के साथ उपसर्ग और प्रत्यय को पार्स करने के लिए), आपका उदाहरण केवल चीजों को बदतर बनाता है। मैं "vUsing" देखता हूं और मेरे सिर में "आवाज करना" सुनता हूं।

— बॉब क्रॉस

@Jon: यदि आपके पास एक चर नाम है जो पूरी तरह से वह नहीं दे रहा है जो वह प्रतिनिधित्व कर रहा है, तो पूरी तरह से इसका मतलब यह है कि इसे कुछ और वर्णनात्मक करने के लिए इसका नाम बदल दिया जाना चाहिए (और हंगेरियन संकेतन एक सुधार नहीं है, बहुत में, बहुत सबसे अच्छा मामला यह लक्षण को ठीक कर रहा है - समस्या को हल नहीं करना)।

— होवडाल

Answer 3

योएल गलत है, और यहाँ क्यों है।

उस "एप्लिकेशन" जानकारी के बारे में वह बात कर रहा है जिसे टाइप सिस्टम में एन्कोड किया जाना चाहिए । आपको यह सुनिश्चित करने के लिए चर नामों पर फ़्लिपिंग पर निर्भर नहीं होना चाहिए कि आप सुरक्षित डेटा की आवश्यकता वाले कार्यों के लिए असुरक्षित डेटा पास नहीं करते हैं। आपको इसे एक प्रकार की त्रुटि करनी चाहिए, ताकि ऐसा करना असंभव हो। किसी भी असुरक्षित डेटा में एक प्रकार होना चाहिए जो असुरक्षित चिह्नित किया गया है, ताकि इसे केवल एक सुरक्षित फ़ंक्शन में पारित नहीं किया जा सके। असुरक्षित से सुरक्षित में बदलने के लिए कुछ प्रकार के सैनिटाइज़ फ़ंक्शन के साथ प्रसंस्करण की आवश्यकता होनी चाहिए।

जोएल की "प्रकार" के रूप में बात करने वाली बहुत सी चीजें प्रकार नहीं हैं; वे वास्तव में, प्रकार हैं।

हालाँकि, अधिकांश भाषाओं में कमी है, एक प्रकार की प्रणाली है जो इस प्रकार के भेदों को लागू करने के लिए पर्याप्त रूप से अभिव्यंजक है। उदाहरण के लिए, यदि C के पास एक प्रकार का "मजबूत टाइपडेफ" होता है (जहां टाइपडेफ नाम में आधार प्रकार के सभी ऑपरेशन थे, लेकिन इसके लिए परिवर्तनीय नहीं था) तो इन समस्याओं का एक बहुत दूर चला जाएगा। उदाहरण के लिए, यदि आप कह सकते हैं, strong typedef std::string unsafe_string;एक नए प्रकार को पेश करने के लिए जिसे एक unsafe_stringstd :: string में परिवर्तित नहीं किया जा सकता है (और इसलिए अधिभार संकल्प आदि में भाग ले सकते हैं आदि) तो हमें मूर्खतापूर्ण उपसर्गों की आवश्यकता नहीं होगी।

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

दूसरे शब्दों में, उद्देश्य "गलत कोड को डेवलपर को गलत दिखना" नहीं होना चाहिए। यह "गलत कोड को संकलक को गलत दिखना चाहिए" होना चाहिए ।

Comments

चर के इरादे को चर के प्रकार के भीतर एन्कोड किया जाना चाहिए, न कि एक नाजुक नामकरण योजना के रूप में इतनी नाजुक चीज को छोड़ दिया जाए।

— DrPizza

मैं इसे संकलक / दुभाषिया का काम भी करना पसंद करूंगा, लेकिन यह गतिशील भाषाओं (पायथन, रूबी, पीएचपी या जावास्क्रिप्ट) के लिए एक बड़ा ओवरहेड होगा।

— बहुत ज्यादा php

"हालांकि, अधिकांश भाषाओं में कमी है, लेकिन एक प्रकार की प्रणाली है जो इस प्रकार के भेदों को लागू करने के लिए पर्याप्त रूप से अभिव्यंजक है" और समस्या है। AppsH ट्वीट्स बग रिपोर्ट की जांच करने के बजाय कोड को देखने वाले प्रोग्रामर को इन भाषाओं का स्पष्ट तरीके से उपयोग करते समय समस्याओं को उजागर करने के लिए एक व्यावहारिक तरीका है।

— नील ट्रोडन

@DrPizza: मेरा मानना ​​है कि आपने एपल हंगेरियन की वकालत करते हुए जोएल को जो महत्वपूर्ण बिंदु दिए हैं, उनमें से एक को याद किया है: यह अंकन केवल बहुत ही व्यावहारिक व्यापार है । संकलक को "गलत कोड" देखने में सक्षम बनाना एक महान लक्ष्य है, लेकिन क्या यह हमेशा इसकी लागत के लायक है?

— यारिक

@DrPizza: Joel is wrongऔर What most languages lack, however, is a type system that's expressive enough to enforce these kind of distinctions.तो, के बाद से सबसे अधिक भाषाओं करते भेद इस तरह लागू करने के लिए अभिव्यक्ति की पर्याप्त कमी है, जोएल है सही। सही?

— संपतश्री

Answer 4

मुझे लगता है कि यह बड़े पैमाने पर स्रोत कोड का सुराग लगाता है।

यह आपको एक जोरदार टाइप की गई भाषा में बहुत अधिक लाभ नहीं देता है। यदि आप किसी भी प्रकार के बेमेल टोमफूलरी का निर्माण करते हैं, तो संकलक आपको इसके बारे में बताएगा।

Comments

वाह। 15 मिनट में 90 प्रतिनिधि। अच्छा निर्णय।

— डस्टमैन

यदि आप इसे प्रकार के लिए उपयोग करते हैं, तो हाँ, यह बेकार है। यह अन्य जानकारी प्रदान करने के लिए उपयोगी है।

— लू फ्रेंको

@ Lou, बिल्कुल - व्यक्तिगत रूप से, मैं अपने चर नामों में एक संशोधन इतिहास संग्रहीत करता हूं: string firstName_wasName_wasNameID_wasSweetCupinCakes

— Shog9

@ सांडर्स: संकलक का उपयोग करके यह जांचने की कोशिश करें कि क्या आपने माप की समान इकाइयों का उपयोग किया है जब दोनों चर प्रकार पूर्णांक हैं।

— इगोर लेविक

@ शोग 9: मुझे लगता है कि आप एप्स हंगेरियन नोटेशन को नहीं समझते थे। यह sFirstName बनाम unFirstName (सुरक्षित बनाम असुरक्षित, अनिश्चित) के बारे में अधिक है, इस तरह से आप इसके बारे में कुछ और जानते हैं। फिर भी मुझे लगता है कि स्टैटिक भाषाओं में यह बेहतर है कि स्ट्रिंग को उपसंस्कृति और सुरक्षित बनाने के लिए स्ट्रिंग को उपप्रकार करें और केवल SafeString को आउटपुट की अनुमति दें। कन्वेंशन ठीक है, लेकिन (अधिक बार) संकलन लागू करना बेहतर है।

— किलोडे

Answer 5

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

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

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

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

ऐप्स हंगेरी मतलब होगा यदि आप विरासत VBScript या VB के प्रारंभिक संस्करणों की तरह, उपयोगकर्ता परिभाषित प्रकार के बिना एक भाषा के साथ काम कर रहे हैं। शायद पर्ल और पीएचपी के शुरुआती संस्करण भी। फिर से, एक आधुनिक संकट में इसका उपयोग शुद्ध कार्गो पंथ है।

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

जोल्स लेख का सामान्य बिंदु - गलत कोड को गलत देखना - एक बहुत अच्छा सिद्धांत है। हालाँकि, बग के खिलाफ एक और बेहतर सुरक्षा है - जब संभव हो - कम्पाइलर द्वारा स्वचालित रूप से पता लगाया जाने वाला गलत कोड हो।

Comments

उपयोगकर्ता-परिभाषित प्रकारों वाली भाषाएं "प्रकार" के बजाय प्रकारों का उपयोग करने के लिए हमेशा व्यावहारिक नहीं होती हैं। जोएल के एप्स हंगेरियन के उपसर्ग "c", "d", "ix" पर विचार करें। क्या आप प्रत्येक आधुनिक भाषाओं में उन लोगों के लिए कस्टम पूर्णांक प्रकारों का उपयोग करते हैं? मुझे ऐसा नहीं लगता। क्योंकि आधुनिक भाषाओं में अभी भी इंडेक्स, काउंट और दो संख्याओं के बीच अंतर के लिए बिल्ट कस्टम पूर्णांक प्रकार नहीं हैं। जब तक हम अभी भी वेनिला ints का उपयोग कर रहे हैं, Apps हंगेरियन गैर-निरर्थक और उपयोगी होंगे।

— एल्ड्रिच कोन्ड्रम

Answer 6

मैं हमेशा अपने सभी प्रोजेक्ट्स के लिए हंगेरियन नोटेशन का उपयोग करता हूं। मुझे यह वास्तव में उपयोगी लगता है जब मैं विभिन्न पहचानकर्ता नामों के 100 के साथ काम कर रहा हूं।

उदाहरण के लिए, जब मुझे एक फ़ंक्शन की आवश्यकता होती है, तो मैं एक स्ट्रिंग टाइप कर सकता हूं जो 's' टाइप कर सकता है और कंट्रोल-स्पेस को हिट कर सकता है और मेरी IDE मुझे 's' के साथ उपसर्गित चर नाम दिखाएगा।

एक और फायदा, जब मैं अहस्ताक्षरित के लिए यू और उप हस्ताक्षर के लिए मैं, मैं तुरंत देखता हूं कि मैं कहां हस्ताक्षर कर रहा हूं और संभावित खतरनाक तरीकों से अहस्ताक्षरित हूं।

मुझे उस समय की संख्या याद नहीं है जब 75000 लाइन कोडबेस में बग्स स्थानीय स्तर पर नामकरण के कारण (मेरे और अन्य लोगों द्वारा) किए गए थे, जो उस वर्ग के मौजूदा सदस्य चर के समान थे। तब से, मैं हमेशा 'm_' सदस्यों के साथ उपसर्ग करता हूं

इसका स्वाद और अनुभव का सवाल है। जब तक आप इसे आज़मा न लें, तब तक इसे खटखटाएं नहीं।

Comments

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

— प्लूमनेटर

आपके पास सदस्य चर के साथ एक अच्छा बिंदु है, हालांकि। लेकिन पायथन जैसी भाषाओं में जहां आपको सदस्यों को स्वयं के साथ योग्यता प्राप्त करने के लिए मजबूर किया जाता है।

— प्लमरेटर

यह उत्पादकता में मदद करने के लिए सिर्फ एक चाल है। जैसे IDE स्वतः पूर्ण। इसके बारे में मौलिक रूप से कुछ भी बुरा नहीं है। मेरा मानना ​​है कि अनुभवी कोडर्स को अपनी शैली का उपयोग करने की अनुमति दी जानी चाहिए। किसी को भी एक निश्चित शैली चुनने के लिए मजबूर करना बुरा है। मैं अब एक एकल डेवलपर के रूप में काम करता हूं, लेकिन जब तक मैंने पहली जगह पर एक सुसंगत शैली का अभाव नहीं किया, तब तक मैं किसी के साथ एक शैली लागू नहीं करूंगा।

— rep_movsd

तो, आप चर नामांकित करने के लिए एक नामकरण सम्मेलन का उपयोग कर रहे हैं, हुह? मुझे सहमत होना चाहिए कि यह थोड़े चतुर है । :-) हालाँकि, मैं जिस तरह से वायर्ड हूं, एंकर पॉइंट (या फिल्टर मानदंड, अगर आपको पसंद है) हमेशा मेरे लिए शब्दार्थ है। शायद ही कभी प्रकार (जब तक यह है अर्थ)। मुझे उम्मीद है कि वह अर्थवान है। टी एल; डॉ: मैं अभी भी के अनुसार नामकरण चर पर कायम था क्या वे से प्रतिनिधित्व कैसे वे प्रतिनिधित्व किया कर रहे हैं।

— प्लूमनेटर

मैंने यह वापस कर दिया क्योंकि मैं हंगरी के पक्ष में था। अब मुझे इसका पछतावा है, और एक चर के लिए कुछ उपसर्ग करने से कभी पीछे नहीं

— हटेगा

Answer 7

आप इस जानकारी को शामिल करने के लिए नंबर एक कारण भूल रहे हैं। इसका आपके, प्रोग्रामर से कोई लेना-देना नहीं है। आपके पास उस सामान को पढ़ने के लिए कंपनी छोड़ने वाले 2 या 3 साल बाद सड़क पर आने वाले व्यक्ति के साथ सब कुछ करना है।

हां, एक आईडीई जल्दी से आपके लिए प्रकारों की पहचान करेगा। हालाँकि, जब आप 'बिजनेस रूल्स' कोड के कुछ लंबे बैचों के माध्यम से पढ़ रहे होते हैं, तो यह जानना अच्छा होता है कि प्रत्येक वेरिएबल पर यह पता लगाने के लिए कि यह किस प्रकार का है। जब मैं strUserID, intProduct या guiProductID जैसी चीजें देखता हूं, तो यह बहुत आसान 'रैंप अप' समय के लिए बनाता है ।

मैं मानता हूँ कि एमएस उनके कुछ नामकरण सम्मेलनों के साथ बहुत दूर चला गया था - मुझे लगता है कि "बहुत अच्छी बात है" ढेर में।

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

Comments

VIM के रूप में (कोई आईडीई नहीं, कोई हाइलाइटिंग नहीं, कोई हॉवर-टेल-यू-व्हाट्स-टाइप) उपयोगकर्ता इस तर्क को बिल्कुल नहीं समझता है। मैं स्वाभाविक रूप से समझता हूं कि नाम वाला एक चर एक स्ट्रिंग है, और एक चर जिसे i या काउंट कहा जाता है वह एक int है। क्या किसी को वास्तव में sName और iCount की आवश्यकता है? यह वास्तव में कैसे मदद करता है? मैं तर्क दूंगा कि आपका उत्पाद आईडी उदाहरण एक विशेष मामला है, और शायद वहां यह ठीक होगा। लेकिन फिर भी, हर जगह ints या तार के साथ उत्पाद आईडी का सुसंगत और प्रतिनिधित्व होना एक बेहतर समाधान होगा, नहीं? पूरा नामकरण एक पुलिस-आउट की तरह लगता है।

— 15

यह स्थिरता के लिए है। हां, "नाम" स्वाभाविक रूप से एक स्ट्रिंग का अर्थ है। लेकिन आप "userid" को क्या मानेंगे? एक गाइड? स्ट्रिंग? पूर्णांक? यहां तक ​​कि कुछ "एक्टेंको" का मान 42 या "23X" हो सकता है। अधिकांश कोड में प्रलेखन काफी विरल है। यह मानक रखरखाव प्रोग्रामर को थोड़ा मदद करता है।

— डेविड

@ डेविड मैं आपके उत्तर से पूरी तरह सहमत हूं - एक नज़र में चर के इरादे को जानकर वह कारण है जो मैं पहले से ही पसंद कर रहा हूं, जेएस जैसी गतिशील भाषा में।

— डैनियल सोकोलोस्की

Answer 8

प्रत्येक चर नाम की शुरुआत में गुप्त वर्णों पर टैपिंग अनावश्यक है और यह दर्शाता है कि चर नाम अपने आप में वर्णनात्मक नहीं है। अधिकांश भाषाओं को वैसे भी घोषणा में परिवर्तनशील प्रकार की आवश्यकता होती है, ताकि जानकारी पहले से ही उपलब्ध हो।

वहाँ भी स्थिति है, जहां रखरखाव के दौरान, एक चर प्रकार को बदलने की आवश्यकता होती है। उदाहरण: यदि "uint_16 u16foo" के रूप में घोषित एक चर को 64-बिट अहस्ताक्षरित होने की आवश्यकता है, तो दो चीजों में से एक होगा:

1. आप प्रत्येक चर नाम को बदलेंगे और बदलेंगे (यह सुनिश्चित करेंगे कि किसी असंबंधित चर को एक ही नाम के साथ न लें), या
2. केवल प्रकार बदलें और नाम न बदलें, जिससे केवल भ्रम पैदा होगा।

Answer 9

जोएल स्पोलस्की ने इस बारे में एक अच्छा ब्लॉग पोस्ट लिखा। http://www.joelonsoftware.com/articles/Wrong.html मूल रूप से यह कठिन अपने कोड बनाने को पढ़ने के लिए जब एक सभ्य आईडीई आप टाइप चर रहा है अगर आप याद नहीं कर सकते चाहते बता देंगे नहीं करने के लिए नीचे आता है। इसके अलावा, यदि आप अपने कोड को पर्याप्त रूप से कम्पाइल करते हैं, तो आपको यह याद रखने की आवश्यकता नहीं है कि एक चर को तीन पृष्ठों के रूप में घोषित किया गया था।

Answer 10

इन दिनों के प्रकार की तुलना में अधिक महत्वपूर्ण नहीं है, जैसे

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

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

Comments

फिर, कोड शायद गुंजाइश के आधार पर इतना नहीं होना चाहिए। :-)

— प्लमनेटर

Answer 11

कोई कारण नहीं है कि आपको हंगेरियन नोटेशन का सही उपयोग नहीं करना चाहिए । यह अलोकप्रियता विशेष रूप से विंडोज एपीआई में हंगेरियन नोटेशन के गलत उपयोग के खिलाफ लंबे समय तक चलने वाले बैक-लैश के कारण है ।

बुरे-पुराने दिनों में, DOS के लिए एक IDE के समान कुछ भी होने से पहले (आपके पास विंडोज के तहत संकलक को चलाने के लिए पर्याप्त मुफ्त मेमोरी नहीं है, इसलिए आपका विकास DOS में किया गया था), आपको कोई मदद नहीं मिली एक चर नाम पर अपने माउस मँडरा। (यह मानते हुए कि आपके पास एक माउस था।) आपके पास जो कुछ भी था उससे निपटने के लिए ईवेंट कॉलबैक फ़ंक्शन थे जिसमें सब कुछ आपके लिए 16-बिट इंट (WORD) या 32-बिट इंट (LONG WORD) के रूप में पास किया गया था। फिर आपको उन पैरामीटर को दिए गए ईवेंट प्रकार के लिए उपयुक्त प्रकारों में डालना होगा। वास्तव में, API का अधिकांश भाग लगभग टाइप-कम था।

परिणाम, इन जैसे पैरामीटर नामों के साथ एक एपीआई:

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

ध्यान दें कि नाम waram और lParam, हालांकि बहुत भयानक हैं, वास्तव में उन्हें param1 और param2 नाम देने से भी बदतर नहीं हैं।

मामलों को बदतर बनाने के लिए, विंडो 3.0 / 3.1 में दो प्रकार के संकेत थे, निकट और दूर। इसलिए, उदाहरण के लिए, स्मृति प्रबंधन फ़ंक्शन लोकलॉक से वापसी मूल्य एक पीवीओआईडी था, लेकिन ग्लोबललॉक से वापसी मूल्य एलपीवीओआईडी (लंबे समय तक 'एल' के साथ) था। उस भयानक संकेतन को तब बढ़ाया गया ताकि एक एल ओन्ग पी ओइंटर स्ट्रिंग उपसर्ग एलपी हो , इसे एक स्ट्रिंग से अलग करने के लिए जो कि बस मैलोकाड था ।

यह कोई आश्चर्य की बात नहीं है कि इस तरह की बात के खिलाफ एक प्रतिक्रिया थी।

Answer 12

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

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

दूसरी ओर, ऐसे मामले भी हो सकते हैं, जहां कंपाइल-टाइम टाइप-चेकिंग भाषाओं को हंगेरियन नोटेशन - शून्य पॉइंटर्स या हेंडले के विन 32 एपीआई में फायदा होगा । ये वास्तविक डेटा प्रकार को बाधित करते हैं, और वहां हंगेरियन नोटेशन का उपयोग करने के लिए योग्यता हो सकती है। फिर भी, यदि कोई निर्माण समय पर डेटा के प्रकार को जान सकता है, तो उपयुक्त डेटा प्रकार का उपयोग क्यों नहीं करना चाहिए।

सामान्य तौर पर, हंगेरियन नोटेशन का उपयोग नहीं करने के लिए कोई कठिन कारण नहीं हैं। यह पसंद, नीतियों और कोडिंग शैली की बात है।

Answer 13

एक पायथन प्रोग्रामर के रूप में, हंगेरियन नोटेशन बहुत तेजी से अलग हो जाता है। अजगर में, मैं अगर कुछ परवाह नहीं है है एक स्ट्रिंग - मुझे परवाह अगर यह कर सकते हैं की तरह काम एक स्ट्रिंग (यानी यह एक है, तो ___str___()विधि है जो एक स्ट्रिंग रिटर्न)।

उदाहरण के लिए, मान लें कि हमारे पास एक पूर्णांक, 12 के रूप में फू है

foo = 12

हंगेरियन नोटेशन हमें बताता है कि हमें उस पूर्णांक को निरूपित करने के लिए उस iFoo या कुछ और को कॉल करना चाहिए, ताकि बाद में हम यह जान सकें कि यह क्या है। पाइथन को छोड़कर, यह काम नहीं करता है, या यों कहें कि इसका कोई मतलब नहीं है। पायथन में, मैं तय करता हूं कि जब मैं इसका उपयोग करता हूं तो मुझे किस प्रकार का चाहिए। क्या मुझे एक तार चाहिए? अगर मैं ऐसा कुछ करता हूँ:

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

नोट %s- स्ट्रिंग। फू एक स्ट्रिंग नहीं है, लेकिन %ऑपरेटर foo.___str___()परिणाम को कॉल करेगा और इसका उपयोग करेगा (यह मौजूद है)। fooअभी भी एक पूर्णांक है, लेकिन हम इसे एक स्ट्रिंग के रूप में मानते हैं यदि हम एक स्ट्रिंग चाहते हैं। यदि हम एक फ्लोट चाहते हैं, तो हम इसे एक फ्लोट के रूप में मानते हैं। पायथन, हंगेरियन नोटेशन जैसी गतिशील रूप से टाइप की जाने वाली भाषाओं में, क्योंकि यह कोई फर्क नहीं पड़ता है कि जब तक आप इसका उपयोग नहीं करते हैं, तब तक कोई बात नहीं होती है, और यदि आपको किसी विशिष्ट प्रकार की आवश्यकता है, तो बस इसे उस प्रकार में डालना सुनिश्चित करें (जैसे float(foo)) जब आप इसका इस्तेमाल करें।

ध्यान दें कि PHP जैसी गतिशील भाषाओं का यह लाभ नहीं है - PHP नियमों के अस्पष्ट सेट के आधार पर पृष्ठभूमि में 'सही काम' करने की कोशिश करता है जिसे लगभग किसी ने याद नहीं किया है, जिसके परिणामस्वरूप अक्सर अनैच्छिक रूप से अप्रत्याशित रूप से गड़बड़ हो जाती है। इस मामले में, किसी प्रकार का नामकरण तंत्र, जैसे $files_countया $file_name, आसान हो सकता है।

मेरे विचार में, हंगेरियन नोटेशन लीच की तरह है। हो सकता है कि अतीत में वे उपयोगी थे, या कम से कम वे उपयोगी लग रहे थे, लेकिन आजकल यह बहुत सारे अतिरिक्त टाइपिंग के लिए बहुत अधिक लाभ नहीं है।

Comments

दिलचस्प है कि पायथन में .str () के साथ आपका उदाहरण भाषा के गतिशील होने का परिणाम नहीं है। जावा, निश्चित रूप से एक गतिशील भाषा नहीं है, वही काम करता है।

— डस्टमैन

C # भी यही काम करता है, भाषा में हर वर्ग .ToString()ऐसा लागू करता है ताकि यह सब मुद्रित हो सके

— इलेक्ट्रिक कॉफ़ी

Answer 14

आईडीई को उस उपयोगी जानकारी को प्रदान करना चाहिए। हो सकता है कि जब IDE बहुत कम उन्नत थे, तो हंगेरियन ने कुछ प्रकार के (कुछ नहीं, बल्कि कुछ प्रकार के) अर्थ बनाए होंगे।

Comments

फिर, आपको आईडीई पर अधिक भरोसा करते हुए भरोसा नहीं करना चाहिए। आखिरकार, आईडीई के बाहर कोड देखा जा सकता है ...

— ट्रॉमापोनी

Answer 15

एप्स हंगेरियन मेरे लिए ग्रीक है - एक अच्छे तरीके से

एक इंजीनियर के रूप में, एक प्रोग्रामर नहीं, मैं तुरंत एप्स हंगरी के गुणों पर जोएल के लेख को ले गया: "मेकिंग रॉन्ग कोड लुक गलत" । मुझे ऐप्प्स हंगेरियन पसंद है क्योंकि यह नकल करता है कि इंजीनियरिंग, विज्ञान और गणित उप और सुपर-स्क्रिप्टेड प्रतीकों (जैसे ग्रीक अक्षर, गणितीय ऑपरेटर, आदि) का उपयोग करके समीकरणों और सूत्रों का प्रतिनिधित्व करते हैं । यूनिवर्सल ग्रेविटी के न्यूटन के नियम का एक विशेष उदाहरण लें : पहले मानक गणितीय संकेतन में, और फिर एप्स हंगेरियाई छद्म-कोड में:

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

गणितीय संकेतन में, सबसे प्रमुख प्रतीक हैं जो चर में संग्रहीत जानकारी के प्रकार का प्रतिनिधित्व कर रहे हैं : बल, द्रव्यमान, स्थिति वेक्टर, आदि। सब्सक्राइबर स्पष्ट करने के लिए दूसरी पहेली खेलते हैं: किस की स्थिति? यह वही है जो एप्स हंगेरियन कर रहा है; यह आपको चर में पहले संग्रहित वस्तु की तरह बता रहा है और फिर बारीकियों में मिल रहा है - निकटतम कोड के बारे में गणितीय संकेतन प्राप्त कर सकते हैं।

स्पष्ट रूप से मजबूत टाइपिंग जोएल के निबंध से सुरक्षित बनाम असुरक्षित स्ट्रिंग उदाहरण को हल कर सकती है, लेकिन आप स्थिति और वेग डॉक्टरों के लिए अलग प्रकार को परिभाषित नहीं करेंगे; दोनों आकार तीन के डबल सरणियाँ हैं और कुछ भी जो आप करने की संभावना रखते हैं वह एक दूसरे पर लागू हो सकती है। इसके अलावा, यह सही स्थिति और वेग (राज्य वेक्टर बनाने के लिए) या उनके डॉट उत्पाद को लेने के लिए सही अर्थ देता है, लेकिन शायद उन्हें जोड़ने के लिए नहीं। टाइपिंग पहले दो की अनुमति कैसे देगी और दूसरे को प्रतिबंधित कर सकती है, और इस तरह की प्रणाली हर संभव ऑपरेशन का विस्तार कैसे करेगी जिसे आप संरक्षित करना चाहते हैं? जब तक आप अपने टाइपिंग सिस्टम में गणित और भौतिकी के सभी सांकेतिक शब्दों में बदलना करने के लिए तैयार नहीं थे।

इन सभी के शीर्ष पर, बहुत सारी इंजीनियरिंग मैटलैब जैसी कमजोर स्तर की उच्च स्तरीय भाषाओं में की जाती है, या फोरट्रान 77 या एडा जैसे पुराने वाले।

इसलिए यदि आपके पास एक फैंसी भाषा है और IDE और Apps हंगेरियन आपकी मदद नहीं करते हैं तो इसे भूल जाओ - बहुत से लोगों को स्पष्ट रूप से है। लेकिन मेरे लिए, एक नौसिखिया प्रोग्रामर से भी बदतर जो कमजोर या गतिशील रूप से टाइप की गई भाषाओं में काम कर रहा है, मैं एप्स हंगेरियन के बिना तेजी से बेहतर कोड लिख सकता हूं।

Answer 16

यह अविश्वसनीय रूप से बेमानी है और बेकार है सबसे आधुनिक आईडीई, जहां वे स्पष्ट बनाने के लिए एक अच्छा काम करते हैं।

प्लस - मेरे लिए - यह सिर्फ intI, strUserName, आदि देखने के लिए परेशान है :)

Comments

जैसा कि ट्रॉमापोनी ने पॉल बैटम को बताया था, आईडीई में हर कोई कोड नहीं देखता है।

— बजे क्रिस चाररबूक

Answer 17

अगर मुझे लगता है कि उपयोगी जानकारी प्रदान की जा रही है, तो मुझे इसे वहां क्यों नहीं डालना चाहिए जहां यह उपलब्ध है?

फिर कौन परवाह करता है कि कोई और क्या सोचता है? यदि आप इसे उपयोगी पाते हैं, तो अंकन का उपयोग करें।

Comments

'क्योंकि मेरे और बाज़ी के अन्य लोगों में से केवल एक ही है जो बाद में मेरे कोड को बनाए रख सकता है। चूंकि वे सभी लोग टीम में हैं (लेकिन वे इसे अभी तक नहीं जानते हैं), मैं कुछ विचार रखना चाहूंगा यदि वे मुझे आगे बढ़ाते हैं।

— डस्टमैन

Answer 18

Im मेरा अनुभव, यह बुरा है क्योंकि:

1 - फिर आप सभी कोड को तोड़ देते हैं यदि आपको चर के प्रकार को बदलने की आवश्यकता होती है (यानी यदि आपको 32 बिट्स पूर्णांक को 64 बिट्स पूर्णांक तक विस्तारित करने की आवश्यकता है);

2 - यह बेकार की जानकारी है क्योंकि प्रकार या तो पहले से ही घोषणा में है या आप एक गतिशील भाषा का उपयोग करते हैं जहां वास्तविक प्रकार पहले स्थान पर इतना महत्वपूर्ण नहीं होना चाहिए।

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

Answer 19

में योएल Spolsky के बनाना गलत कोड को देखो गलत वे बताते हैं कि क्या हर कोई के रूप में हंगेरी संकेतन (जो वह सिस्टम हंगेरी कॉल) नहीं क्या यह वास्तव में (वह क्या Apps हंगेरी कॉल) बनना था किया गया था के बारे में सोचती। के लिए नीचे स्क्रॉल मैं हंगरी हूँ इस चर्चा को देखने के लिए शीर्षक नहीं।

असल में, सिस्टम हंगेरियन बेकार है। यह सिर्फ आपको वही बात बताता है जो आपका कंपाइलर और / या IDE आपको बताएगा।

ऐप्स हंगेरियन आपको बताता है कि चर का क्या मतलब है, और वास्तव में उपयोगी हो सकता है।

Answer 20

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

Comments

मुझे कभी ISomething नहीं मिला। अगर यह एक-योग्य है, तो इसका मतलब है कि इंटरफ़ेस से संबंधित है। (कम से कम जावा में)

— ट्यूनरंच

Answer 21

यदि यह नियंत्रण की सूची आपके IDE में वर्णक्रमीय पुल-डाउन सूची में दिखाई देती है, तो यह प्रपत्र (btnOK, txtLastName आदि) पर नियंत्रणों के नामकरण के लिए एक उपयोगी सम्मेलन है।

Answer 22

मैं ASP.NET सर्वर नियंत्रण के साथ हंगेरी संकेतन का उपयोग करते हैं केवल , अन्यथा मैं यह बहुत कठिन काम करने की क्या नियंत्रण फार्म पर क्या कर रहे हैं।

यह कोड स्निपेट लें:

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

अगर कोई हंगरी के बिना नियंत्रण नामों के उस सेट के होने का एक बेहतर तरीका दिखा सकता है, तो मैं इसे स्थानांतरित करने के लिए लुभाऊंगा।

Answer 23

जोएल का लेख बहुत अच्छा है, लेकिन यह एक प्रमुख बिंदु को छोड़ देता है:

हंगेरियन एक विशेष 'विचार' (दयालु + पहचानकर्ता नाम) को अद्वितीय, या निकट-अद्वितीय, कोडबेस के पार बनाता है - यहां तक ​​कि एक बहुत बड़ा कोडबेस भी।

कोड रखरखाव के लिए यह बहुत बड़ा है। इसका अर्थ है कि आप उस 'विचार' के सभी उल्लेखों को खोजने के लिए अच्छे ol 'सिंगल-लाइन टेक्स्ट सर्च (grep, findstr,' all files ') का उपयोग कर सकते हैं।

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

आपको यहां भी थोड़ा सावधान रहना होगा - जैसे कि C / C ++ मैक्रोज़ में टोकन चिपकाने से पहचानकर्ता के उल्लेख छिप सकते हैं। ऐसे मामलों को कोडिंग कन्वेंशनों का उपयोग करके निपटाया जा सकता है, और वैसे भी वे कोडवर्ड में केवल पहचानकर्ताओं के अल्पसंख्यक को प्रभावित करते हैं।

PS प्रकार के सिस्टम बनाम हंगेरियन का उपयोग करने के बारे में - यह दोनों का उपयोग करने के लिए सबसे अच्छा है। यदि कंपाइलर आपके लिए इसे नहीं पकड़ेगा तो आपको गलत दिखने के लिए केवल गलत कोड की आवश्यकता है। ऐसे बहुत सारे मामले हैं जहां संकलक को पकड़ना संभव है। लेकिन जहां यह संभव है - हां, कृपया इसके बजाय ऐसा करें!

व्यवहार्यता पर विचार करते समय, हालांकि, प्रकार को विभाजित करने के नकारात्मक प्रभावों पर विचार करें। C # में, गैर-निर्मित प्रकार के साथ 'int' लपेटने के भारी परिणाम हैं। तो यह कुछ स्थितियों में समझ में आता है, लेकिन उन सभी में नहीं।

Answer 24

हंगेरियन नोटेशन के लाभों का वर्णन करना

• यह चरों को अलग करने का एक तरीका प्रदान करता है।

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

• यह कोड को अधिक पठनीय बनाता है।

मैंने पाया है कि हंगेरियन नोटेशन लोगों को उनके चर नामों से आलसी बनाता है। उनके पास इसे भेद करने के लिए कुछ है, और उन्हें इसके उद्देश्य को विस्तृत करने की कोई आवश्यकता नहीं है। यह वह है जो आप आम तौर पर हंगेरियन नॉटेड कोड बनाम मॉडर्न में पाएंगे: sSQL बनाम groupSelectSql ( या आमतौर पर कोई sSQL बिल्कुल नहीं क्योंकि उन्हें माना जाता है कि ORM जो पहले डेवलपर्स द्वारा डाला गया था) का उपयोग कर रहे हैं। ), sValtion बनाम formCollectionValue ( या आमतौर पर कोई sValue भी नहीं होता है, क्योंकि वे MVC में होते हैं और इसकी मॉडल बाइंडिंग सुविधाओं का उपयोग करना चाहिए ), sType बनाम पब्लिश सोर्स आदि।

यह पठनीयता नहीं हो सकती। मैं और अधिक sTemp1, sTemp2 ... किसी भी दिए गए बजाए हुए VB6 बचे हुए हिस्से से sTempN को देखता हूं।

• यह त्रुटियों को रोकता है।

यह संख्या 2 के आधार पर होगा, जो कि गलत है।

Answer 25

गुरु के शब्दों में:

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

एक दिलचस्प पढ़ना, हमेशा की तरह।

अर्क:

"किसी ने, कहीं, सिमोनी के पेपर को पढ़ा, जहां उन्होंने" टाइप "शब्द का इस्तेमाल किया और उन्हें लगा कि उनका मतलब टाइप है, क्लास की तरह, टाइप सिस्टम की तरह, जैसे कंपाइलर चेक करता है। उन्होंने ऐसा नहीं किया। उन्होंने बहुत ध्यान से समझाया। वास्तव में "शब्द" से उनका क्या मतलब था, लेकिन इससे कोई फायदा नहीं हुआ। नुकसान हुआ था।

"लेकिन एप्स हंगेरियन के लिए अभी भी बहुत अधिक मूल्य है, जिसमें यह कोड में कोलाजेशन को बढ़ाता है, जिससे कोड को पढ़ना, लिखना, डिबग करना और रखरखाव करना आसान हो जाता है, और सबसे महत्वपूर्ण बात यह है कि यह गलत कोड को गलत दिखता है।"

सुनिश्चित करें कि आपके पास जोएल ऑन सॉफ्टवेयर पढ़ने से पहले कुछ समय है। :)

Comments

अब कोई समय नहीं है कि मेरे पास स्टाकेवरफ्लो है। मुझे लगता है कि इस परियोजना के साथ स्पॉलस्की की मात्र संगति अवश्य कर रही है। :)

— डस्टमैन

Answer 26

कई कारण:

• कोई भी आधुनिक आईडीई आपको चर पर अपना माउस मँडरा करके चर प्रकार देगा।
• अधिकांश प्रकार के नाम लंबे होते हैं (सोचते हैं कि HttpClientRequestProvider ) को उपसर्ग के रूप में यथोचित रूप से उपयोग किया जाता है।
• प्रकार की जानकारी सही जानकारी नहीं लेती है , यह केवल चर के उद्देश्य को रेखांकित करने के बजाय परिवर्तनशील घोषणा को परिभाषित कर रही है ( myInteger बनाम पृष्ठ देखें )।

Answer 27

मुझे नहीं लगता कि हर कोई इसके खिलाफ है। स्थिर प्रकार के बिना भाषाओं में, यह बहुत उपयोगी है। मैं निश्चित रूप से इसे पसंद करता हूं जब यह जानकारी देने के लिए उपयोग किया जाता है जो पहले से टाइप में नहीं है। सी की तरह, चार * szName का कहना है कि चर एक अशक्त समाप्त स्ट्रिंग को संदर्भित करेगा - जो कि चार * में निहित नहीं है - निश्चित रूप से, एक टंकण भी मदद करेगा।

जोएल ने मैरी का एन्कोड किया गया था या नहीं, यह बताने के लिए आयु का उपयोग करने पर एक शानदार लेख था:

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

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

Comments

मुझे लगता है कि पहला वाक्य इस पृष्ठ पर उत्तरों को बांध सकता है।

— डस्टमैन

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

— प्लमरेटर

हर चार नहीं * एक शून्य समाप्त सी स्ट्रिंग है। हंगेरियन का उपयोग हर चर के लिए इसका उपयोग करना है, यहां तक ​​कि जो सामान्य मामले में आते हैं। अंततः, मुझे लगता है कि आप ऐसा करते हैं - और इसलिए मैं इसका उपयोग सी

— लू फ्रेंको

Answer 28

बेशक जब 99% प्रोग्रामर किसी बात पर सहमत होते हैं, तो कुछ गलत होता है। यहां वे सहमत हैं इसका कारण यह है कि उनमें से अधिकांश ने कभी भी हंगेरियन नोटेशन का सही उपयोग नहीं किया है।

एक विस्तृत तर्क के लिए, मैं आपको एक ब्लॉग पोस्ट के बारे में बताता हूं जिसे मैंने इस विषय पर बनाया है।

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

Answer 29

जब मैंने हंगेरियन नोटेशन का आविष्कार किया था और जिस समय मैं इसे नफरत करता था एक परियोजना पर इसका उपयोग करने के लिए मजबूर किया गया था, उस समय के बारे में मैंने बहुत कोड करना शुरू कर दिया था।

थोड़ी देर के बाद मुझे एहसास हुआ कि जब यह ठीक से किया गया था तब वास्तव में मदद मिली थी और इन दिनों मैं इसे प्यार करता हूं।

लेकिन सभी चीजों की तरह, इसे सीखना और समझना और इसे ठीक से करने में समय लगता है।

Answer 30

विशेषकर Microsoft द्वारा हंगेरियन संकेतन का दुरुपयोग किया गया था, जो चर नाम की तुलना में लंबे समय तक उपसर्गों के लिए अग्रणी है, और यह काफी कठोर है, खासकर जब आप Win16 में एक ही प्रकार (कुख्यात लाराम / लहरम) को Win16 में विभिन्न प्रकार / आकार में बदलते हैं )।

इस प्रकार, इस दुरुपयोग के कारण, और एम $ के उपयोग के कारण, इसे बेकार मान लिया गया।

मेरे काम पर, हम जावा में कोड करते हैं, लेकिन MFC दुनिया के संस्थापक नाम हैं, इसलिए समान कोड शैली (संरेखित ब्रेसिज़) का उपयोग करें, मुझे यह पसंद है!, विधि नाम के लिए राजधानियाँ, मैं इसका उपयोग कर रहा हूँ, m_ जैसे उपसर्ग वर्ग के सदस्य (फ़ील्ड) ), s_ से स्थिर सदस्य, आदि)।

और उन्होंने कहा कि सभी प्रकारों में एक उपसर्ग होना चाहिए जो इसके प्रकार को दर्शाता है (जैसे। एक बफ़ररेडर का नाम brData है)। जो एक बुरा विचार के रूप में दिखाया गया है, जैसे कि प्रकार बदल सकते हैं लेकिन नाम का पालन नहीं होता है, या कोडर इन उपसर्गों के उपयोग में सुसंगत नहीं हैं (मैं भी aBuffer, theProxy, आदि देखें!)।

व्यक्तिगत रूप से, मैंने कुछ उपसर्गों के लिए चुना है जो मुझे उपयोगी लगते हैं, सबसे महत्वपूर्ण है बूलियन वेरिएबल उपसर्ग, क्योंकि वे केवल वही हैं जहां मैं वाक्यविन्यास की अनुमति देता हूं if (bVar)( जैसे कुछ मूल्यों के ऑटोकैस्ट का उपयोग सही या गलत के लिए नहीं)। जब मैंने सी में कोडित किया, तो मैंने मॉलोक के साथ आवंटित चर के लिए एक उपसर्ग का उपयोग किया, एक अनुस्मारक के रूप में इसे बाद में मुक्त किया जाना चाहिए। आदि।

इसलिए, मूल रूप से, मैं इस धारणा को एक पूरे के रूप में अस्वीकार नहीं करता हूं, लेकिन जो मेरी आवश्यकताओं के लिए उचित लगता है वह लिया।
और निश्चित रूप से, जब कुछ परियोजना (काम, खुला स्रोत) में योगदान करते हैं, तो मैं जगह में सम्मेलनों का उपयोग करता हूं!