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




language-agnostic naming-conventions (24)

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

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


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

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

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


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

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

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

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


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


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

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

foo = 12

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

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

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

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

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


Debunking the benefits of Hungarian Notation

  • It provides a way of distinguishing variables.

If the type is all that distinguishes the one value from another, then it can only be for the conversion of one type to another. If you have the same value that is being converted between types, chances are you should be doing this in a function dedicated to conversion. (I have seen hungarianed VB6 leftovers use strings on all of their method parameters simply because they could not figure out how to deserialize a JSON object, or properly comprehend how to declare or use nullable types. ) If you have two variables distinguished only by the Hungarian prefix, and they are not a conversion from one to the other, then you need to elaborate on your intention with them.

  • It makes the code more readable.

I have found that Hungarian notation makes people lazy with their variable names. They have something to distinguish it by, and they feel no need to elaborate to its purpose. This is what you will typically find in Hungarian notated code vs. modern: sSQL vs. groupSelectSql ( or usually no sSQL at all because they are supposed to be using the ORM that was put in by earlier developers. ), sValue vs. formCollectionValue ( or usually no sValue either, because they happen to be in MVC and should be using its model binding features ), sType vs. publishSource, etc.

It can't be readability. I see more sTemp1, sTemp2... sTempN from any given hungarianed VB6 leftover than everybody else combined.

  • It prevents errors.

This would be by virtue of number 2, which is false.


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


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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


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

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

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

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

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

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

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


In the words of the master:

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

An interesting reading, as usual.

Extracts:

"Somebody, somewhere, read Simonyi's paper, where he used the word “type,” and thought he meant type, like class, like in a type system, like the type checking that the compiler does. He did not. He explained very carefully exactly what he meant by the word “type,” but it didn't help. The damage was done."

"But there's still a tremendous amount of value to Apps Hungarian, in that it increases collocation in code, which makes the code easier to read, write, debug, and maintain, and, most importantly, it makes wrong code look wrong."

Make sure you have some time before reading Joel On Software. :)


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


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.


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


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.


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

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


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

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

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


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

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

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

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


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

यह आपको दृढ़ता से टाइप की गई भाषा में भी ज्यादा लाभ नहीं पहुंचाता है। यदि आप किसी भी तरह का मेल नहीं खाते टॉमफूलरी करते हैं, तो संकलक आपको इसके बारे में बताएगा।


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

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

कोड रखरखाव के लिए यह बहुत बड़ा है। इसका मतलब है कि आप उस 'विचार' के हर उल्लेख को खोजने के लिए अच्छी ओल 'सिंगल-लाइन टेक्स्ट सर्च (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.


जोएल गलत है, और यही कारण है कि।

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

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

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

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

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


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

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


The Hungarian notation was abused, particularly by Microsoft, leading to prefixes longer than the variable name, and showing it is quite rigid, particularly when you change the types (the infamous lparam/wparam, of different type/size in Win16, identical in Win32).

Thus, both due to this abuse, and its use by M$, it was put down as useless.

At my work, we code in Java, but the founder cames from MFC world, so use similar code style (aligned braces, I like this!, capitals to method names, I am used to that, prefix like m_ to class members (fields), s_ to static members, etc.).

And they said all variables should have a prefix showing its type (eg. a BufferedReader is named brData). Which shown as being a bad idea, as the types can change but the names doesn't follow, or coders are not consistent in the use of these prefixes (I even see aBuffer, theProxy, etc.!).

Personally, I chose for a few prefixes that I find useful, the most important being b to prefix boolean variables, as they are the only ones where I allow syntax like if (bVar) (no use of autocast of some values to true or false). When I coded in C, I used a prefix for variables allocated with malloc, as a reminder it should be freed later. Etc.

So, basically, I don't reject this notation as a whole, but took what seems fitting for my needs.
And of course, when contributing to some project (work, open source), I just use the conventions in place!







hungarian-notation