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




language-agnostic naming-conventions (20)

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

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

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

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


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

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

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

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

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

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

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


vUsing adjHglish nnotation vmakes nreading ncode adjdif मुश्किल।


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

जोएल स्पॉस्की द्वारा इस उत्कृष्ट लेख को पढ़ें: गलत कोड देखो गलत बनाना

संक्षेप में, हंगेरियन नोटेशन जहां आप अपने वैरिएबल नामों को उनके type (स्ट्रिंग) (सिस्टम हंगरी) के साथ उपसर्ग करते हैं, यह खराब है क्योंकि यह बेकार है।

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


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

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

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

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


इन दिनों टाइप करने के मुकाबले ज्यादा महत्वपूर्ण नहीं है, उदाहरण के लिए

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

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


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

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

नतीजा, पैरामीटर नाम वाले एपीआई इनके जैसे:

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

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

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

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


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

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

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

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

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

पीएस प्रकार बनाम हंगरी का उपयोग करने के बारे में बिंदु पर - दोनों का उपयोग करना सबसे अच्छा है। यदि संकलक इसे आपके लिए नहीं पकड़ पाएगा तो आपको केवल गलत देखने के लिए गलत कोड चाहिए। There are plenty of cases where it is infeasible to make the compiler catch it. But where it's feasible - yes, please do that instead!

When considering feasibility, though, do consider the negative effects of splitting up types. eg in C#, wrapping 'int' with a non-built-in type has huge consequences. So it makes sense in some situations, but not in all of them.


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


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

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

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

मैं केवल एएसपी.नेट सर्वर नियंत्रण के साथ हंगेरियन नोटेशन का उपयोग करता हूं, अन्यथा मुझे यह पता लगाने में बहुत मुश्किल लगता है कि फ़ॉर्म पर कौन से नियंत्रण हैं।

इस कोड स्निपेट लो:

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

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


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

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

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

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


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


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


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

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

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

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

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

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

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


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

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

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

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


I don't think everyone is rabidly against it. In languages without static types, it's pretty useful. I definitely prefer it when it's used to give information that is not already in the type. Like in C, char * szName says that the variable will refer to a null terminated string -- that's not implicit in char* -- of course, a typedef would also help.

Joel had a great article on using hungarian to tell if a variable was HTML encoded or not:

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

Anyway, I tend to dislike Hungarian when it's used to impart information I already know.


I started coding pretty much the about the time Hungarian notation was invented and the first time I was forced to use it on a project I hated it.

After a while I realised that when it was done properly it did actually help and these days I love it.

But like all things good, it has to be learnt and understood and to do it properly takes time.



Several reasons:

  • Any modern IDE will give you the variable type by simply hovering your mouse over the variable.
  • Most type names are way long (think HttpClientRequestProvider ) to be reasonably used as prefix.
  • The type information does not carry the right information, it is just paraphrasing the variable declaration, instead of outlining the purpose of the variable (think myInteger vs. pageSize ).




hungarian-notation