हंगेरियन नोटेशन का उपयोग न करने का क्या लाभ है?


101

जिन चीजों से मैं संघर्ष करता हूं उनमें से एक हंगेरियन नोटेशन का उपयोग नहीं कर रही है। मैं चर परिभाषा में जाने के लिए नहीं देखना चाहता कि यह किस प्रकार का है। जब कोई परियोजना व्यापक हो जाती है, तो 'बूल' द्वारा उपसर्ग किए गए एक चर को देखने में सक्षम होना अच्छा है और पता है कि यह 0/1 मान के बजाय सही / गलत की तलाश कर रहा है

मैं SQL Server में भी बहुत काम करता हूं। मैं अपनी संग्रहीत प्रक्रियाओं को 'sp' के साथ और मेरी तालिकाओं को 'tbl' के साथ उपसर्ग करता हूं, क्रमशः डेटाबेस में मेरे सभी चर का उल्लेख नहीं करता।

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


39
आप किस भाषा / आईडीई का उपयोग करते हैं? विजुअल स्टूडियो में, आपको चर का प्रकार जानने के लिए परिभाषा में जाने की जरूरत नहीं है, क्योंकि IDE आपको देता है। उन भाषाओं में जहां प्रकार लागू नहीं होते हैं, जैसे कि PHP, आपको अधिकांश समय टाइप करने की आवश्यकता नहीं है (चूंकि आप एक बूलियन को 0 या 1 असाइन कर सकते हैं)।
आर्सेनी मूरज़ेंको 17

10
@ मेनमा मुझे यकीन नहीं है कि PHP में एक मूल्य के प्रकार को नहीं जानने का एक अच्छा कारण है।
री मियासका

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

20
हंगेरियन नोटेशन का उपयोग न करने का क्या फायदा है "अपने सहकर्मियों से नफरत नहीं किया जा रहा है" मन में आता है ...
शॉन पैट्रिक फ्लॉयड

25
adjH ट्वीट्स nNotation vIs adjHard prepTo vRead।
dan04

जवाबों:


148

क्योंकि इसकी मूल मंशा (देखें http://www.joelonsoftware.com/articles/Wrong.html और http://fplanque.net/Blog/devblog/2005/05/11/h ट्वीट्स_notation_on_steroids ) को गलत समझा गया है और यह ( ab) लोगों को यह याद रखने में मदद करने के लिए उपयोग किया जाता है कि जब वे जिस भाषा का उपयोग करते हैं वह एक प्रकार का वैधानिक रूप से टाइप नहीं किया जाता है। किसी भी वैधानिक रूप से टाइप की गई भाषा में, आपको यह बताने की ज़रूरत नहीं है कि उपसर्गों के अतिरिक्त गिट्टी आपको यह बताने के लिए कि चर किस प्रकार का है। कई अनकैप्ड स्क्रिप्ट भाषाओं में यह मदद कर सकता है, लेकिन अक्सर इसे पूरी तरह से अलविदा बनने के लिए दुरुपयोग किया गया है। दुर्भाग्य से, हंगेरियन संकेतन के मूल इरादे पर वापस जाने के बजाय, लोगों ने इसे उन "बुराई" चीजों में से एक बना दिया है जिनसे आपको बचना चाहिए।

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

अपडेट (डेलान द्वारा टिप्पणी के जवाब में)

IMHO के दुरुपयोग वाले संस्करण को प्लेग की तरह टाला जाना चाहिए क्योंकि:

  • यह नामकरण को जटिल बनाता है। जब (ab) हंगेरियन नोटेशन का उपयोग किया जाता है, तो हमेशा चर्चा होगी कि उपसर्गों को कितना विशिष्ट होना चाहिए। उदाहरण के लिए: listboxXYZया MyParticularFlavourListBoxXYZ
  • यह चर नामों को लंबे समय तक समझने के बिना बनाता है कि चर क्या है।
  • यह अभ्यास की वस्तु को पराजित करता है जब लंबे उपसर्गों से बचने के लिए ये संक्षिप्त रूप में संक्षिप्त हो जाते हैं और आपको यह जानने के लिए एक शब्दकोश की आवश्यकता होती है कि प्रत्येक संक्षिप्त नाम का अर्थ क्या है। एक है uiएक अहस्ताक्षरित पूर्णांक? एक अपरिचित गणना इंटरफ़ेस? उपयोगकर्ता इंटरफेस के साथ कुछ करना है? और वे चीजें लंबी हो सकती हैं । मैंने 15 से अधिक प्रतीत होने वाले यादृच्छिक वर्णों के उपसर्गों को देखा है जो कि सटीक प्रकार के संस्करण को व्यक्त करने वाले हैं, लेकिन वास्तव में केवल रहस्य हैं।
  • यह तेजी से पुराना हो जाता है। जब आप परिवर्तनशील लोगों के प्रकार को हमेशा के लिए बदलते हैं (lol) परिवर्तन को प्रतिबिंबित करने के लिए उपसर्ग को अद्यतन करना भूल जाते हैं, या जानबूझकर इसे अपडेट नहीं करते हैं क्योंकि यह कोड परिवर्तन को ट्रिगर करेगा जहां हर जगह var का उपयोग किया जाता है ...
  • यह कोड के बारे में बात करने में कठिनाई करता है क्योंकि "@ जी।" कहा: हंगेरियन नोटेशन के साथ परिवर्तनीय नाम आमतौर पर मुश्किल से उच्चारण वर्णमाला सूप हैं। यह पठनीयता और चर्चा कोड को रोकता है, क्योंकि आप किसी भी नाम को 'नहीं' कह सकते हैं।
  • ... बहुत अधिक है कि मैं इस समय याद नहीं कर सकते। हो सकता है क्योंकि मुझे लंबे समय तक दुर्व्यवहार वाले हंगेरियन संकेतन से निपटने की खुशी नहीं है ...

9
@ सर्फर ५१३: वास्तव में, मैं नामकरण को पसंद करता हूं जब नामकरण नियंत्रित करता है। मेरे लिए यह सभी नियंत्रणों को खोजने के लिए कहीं अधिक दिलचस्प है जो सभी संपादित नियंत्रणों को खोजने की तुलना में किसी विशिष्ट विषय / पहलू से निपटते हैं ... जब मैं उस नियंत्रण को खोजना चाहता हूं जहां उपयोगकर्ता क्लाइंट नाम में टाइप कर सकता है, तो मैं शिकार करना शुरू करूंगा। क्लाइंट के बजाय txt, क्योंकि यह एक txt (एडिट) नहीं हो सकता है, लेकिन एक मेमो या एक रिचडिट या a ... पहले से दर्ज किए गए क्लाइंट नामों में इसे खोजने की अनुमति देने के लिए एक कॉम्बो बॉक्स भी हो सकता है ...
Marjan Venema

8
@ सर्फर ५१३: और आजकल मैं केवल दो चीजों के बीच अंतर करते हुए प्रत्यय का उपयोग करता हूं जो एक ही चीज़ से निपटते हैं। उदाहरण के लिए लेबल और क्लाइंट नाम के लिए संपादन। और काफी बार प्रत्यय नियंत्रण के प्रकार से संबंधित नहीं होते हैं, लेकिन इसके उद्देश्य के लिए: उदाहरण के लिए ClientCaption और ClientInput।
मार्जन वेनमा

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

4
'... गाली वाले संस्करण को पट्टिका की तरह टाला जाता है ...' जो कहना है, टार्टर और मसूड़े की सूजन से थोड़ा कम बचा है? ;-)
बेन मोशेर

4
@ मार्जन: बेशक इस पर एक कंपाइलर उठाया जा सकता था। यदि प्रत्येक इकाई को एक प्रकार से दर्शाया जाता है, तो आप गलती से दूसरे के लिए पास नहीं कर सकते। यहाँ, यदि आपके पास एक AbsoluteXTypeऔर एक है RelativeYType, तो आप गलती से एक एक्स निरपेक्ष एक के लिए वाई रिश्तेदार समन्वय पारित नहीं कर सकते थे। मैं उन चर को पसंद करता हूं जो असंगत प्रकार के होने के बजाय असंगत संस्थाओं का प्रतिनिधित्व करते हैं। संकलक देखभाल उपसर्गों (या प्रत्ययों) के लिए नहीं है।
मैथ्यू एम।

74

हंगेरियन नोटेशन आधुनिक दिन के प्रोग्रामिंग वातावरण और टॉटोलॉजी के रूप में एक नामकरण विरोधी पैटर्न है ।

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

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


2
"जब आप intकिसी भिन्न प्रकार से अपना परिवर्तन करते हैं तो क्या होता है long..." सरल: <व्यंग्य> नाम मत बदलो क्योंकि इसमें यह नहीं बताया गया है कि परिवर्तन कितने स्थानों पर होगा। </ sarcasm> तो अब आपके पास एक चर है जिसका हंगेरियन नाम इसके कार्यान्वयन के साथ संघर्ष करता है। चर / फ़ंक्शन की सार्वजनिक दृश्यता होने पर नाम बदलने का प्रभाव कितना व्यापक होगा, यह बताने का कोई तरीका नहीं है।
डेविड हैमेन

2
जुड़ा हुआ लेख शानदार है, और पढ़ने लायक है। +1
मार्टी पिट

6
@ डेविड केवल Win32 एपीआई को देखें जो कि चर, मापदंडों, और यहां तक ​​कि विधि नामों से युक्त है, जो हंगेरियन नोटेशन (एमएस में एक आवश्यकता है) का उपयोग करते हुए 8 बिट या 16 बिट मूल्य का संकेत देते हैं जब वास्तव में वे सभी 32 बिट हो गए हैं 1994 में विंडोज 95 के वापस आने के बाद से मान (लगभग 17 साल पहले)।
jwenting

2
@ सुरक्षित: मैं तर्क दूंगा कि स्वचालित परीक्षण क्या होना चाहिए। प्रोग्रामर नहीं।
जोएल

2
@ सुरक्षित रूप से इन-हाउस एप्लिकेशन नहीं है, लेकिन यदि आप विंडोज एपीआई जैसे सार्वजनिक एपीआई बनाए रख रहे हैं, तो यह एक बड़ी समस्या है।
23'11

51

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

के लाभ नहीं हंगेरी अंकन का उपयोग अपने नुकसान के मूल रूप से केवल परिहार है:

  • कंपाइलर द्वारा टाइप-चेकिंग करने पर हंगेरियन नोटेशन बेमानी है। टाइप-जाँच प्रदान करने वाली भाषाओं के लिए कंपाइलर का उपयोग सुनिश्चित करता है कि एक चर का उपयोग अपने प्रकार के अनुरूप हो; आंख से जांच बेमानी है और मानवीय भूल के अधीन है।

  • सभी आधुनिक एकीकृत विकास परिवेश मांग पर चर प्रकार प्रदर्शित करते हैं, और स्वचालित रूप से ध्वज संचालन करते हैं जो असंगत प्रकारों का उपयोग करते हैं, जिससे धारणा काफी हद तक अप्रचलित हो जाती है।

  • जब यह, कई गुण का प्रतिनिधित्व करने में के रूप में प्रयोग किया जाता है हंगेरी संकेतन भ्रमित हो जाता है a_crszkvc30LastNameColएक डेटाबेस स्तंभ की सामग्री पकड़े एक निरंतर संदर्भ तर्क,: LastNameप्रकार की varchar(30)जो तालिका के प्राथमिक कुंजी का हिस्सा है।

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

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

  • हंगरी संकेतन फीचर-रिच कोड संपादकों का उपयोग करने के लाभों को दृढ़ता से कम करता है जो चर नामों पर पूरा होने का समर्थन करते हैं, प्रोग्रामर के लिए पहले पूरे प्रकार के विनिर्देशक को इनपुट करना होता है।

  • यह कोड को कम पठनीय बनाता है, चर के उद्देश्य को अनावश्यक प्रकार और स्कूपिंग उपसर्गों के साथ जोड़कर।

  • अतिरिक्त प्रकार की जानकारी अपर्याप्त रूप से अधिक वर्णनात्मक नाम बदल सकती है। जैसे sDatabaseपाठक को नहीं बताता कि यह क्या है। databaseNameअधिक वर्णनात्मक नाम हो सकता है।

  • जब नाम पर्याप्त रूप से वर्णनात्मक होते हैं, तो अतिरिक्त प्रकार की जानकारी बेमानी हो सकती है। उदाहरण के firstNameलिए सबसे अधिक संभावना है एक स्ट्रिंग। इसलिए इसका नामकरण sFirstNameकेवल कोड में अव्यवस्था जोड़ता है।

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


1
यह सही उत्तर होना चाहिए। यह कितना अच्छा है। +1
सईद नेमाटी

तुम बहुत दयालु हो, सईद। मैं आपकी प्रशंसा को महत्व देता हूं लेकिन इस प्रश्न के अन्य उत्तर वास्तव में बहुत अच्छे हैं।
फाल्कन

11
एक ही वाक्य के लिए अपवित्र: " अधिकांश समय, एक चर के उपयोग को जानने का अर्थ है कि यह अपने प्रकार को जानता है। इसके अलावा, यदि चर का उपयोग ज्ञात नहीं है, तो यह अपने प्रकार से घटाया नहीं जा सकता है। " - IMHO, यह हंगेरियन अंकन से बचने का # 1 कारण है।
डैनियल प्रीडेन

19

MS SQL सर्वर विशिष्ट समस्या के रूप में:

'Sp_' के साथ उपसर्गित किसी भी संग्रहीत प्रक्रिया को पहले मास्टर डेटाबेस में खोजा जाता है बजाय इसके कि इसे बनाया जाता है। इससे संग्रहीत कार्यविधि निष्पादित होने में देरी होगी।


4
वहाँ कुछ बहुत अच्छी जानकारी के लिए +1। मैं 'sp' का उपयोग अपने संग्रहित उपसर्ग के रूप में करता हूं, 'sp_' नहीं। लेकिन सभी एक ही निश्चित रूप से एक बहुत ही दिलचस्प तथ्य है और एक संग्रहीत खरीद उपसर्ग के रूप में 'sp_' का उपयोग नहीं करने का एक ठोस कारण है।

2
+1 मैं इस कभी नहीं जानता था, और जब मैं एसक्यूएल सर्वर पर काम शुरू कर रोजगार के मेरे घर पर सब एस.पी. उपसर्ग के थे sp_सम्मेलन के साथ तो मैं बस अटक गया।
माइकल

महान बिंदु है, लेकिन इस सवाल (वर्ग और नहीं _sp का उपयोग करके) के साथ कुछ नहीं करना है। यह उन वस्तुओं के लिए स्कीमा नाम को छोड़ने जैसा है जो डिफ़ॉल्ट स्कीमा में नहीं हैं।
जेफ़ओ

1
उपयोगकर्ता संग्रहीत प्रक्रियाओं के लिए, मैंने पारंपरिक रूप से 'usp_' का उपयोग किया। यह उल्लेख की गई समस्या से बचने और पाठक के लिए यह जानने के लिए कि क्या स्पोक सिस्टम या उपयोगकर्ता है।
छाता

15

IMO हंगरी का उपयोग नहीं करने का सबसे बड़ा लाभ यह तथ्य है कि यह आपको सार्थक नामों का उपयोग करने के लिए मजबूर करता है । यदि आप चर का ठीक से नामकरण कर रहे हैं, तो आपको तुरंत पता होना चाहिए कि यह किस प्रकार का है या किसी भी अच्छी तरह से डिज़ाइन की गई प्रणाली में इसे जल्दी से कम करने में सक्षम है। अगर आपको यह जानने के लिए कि सभी प्रकार के उपसर्गों पर निर्भर strया blnउससे अधिक की जरूरत objहै, तो चर किस प्रकार का है, मैं तर्क देता हूं कि यह एक नामकरण मुद्दे को इंगित करता है - या तो सामान्य रूप से खराब चर नाम या अर्थ बताने के लिए बहुत सामान्य।

विडंबना यह है कि व्यक्तिगत अनुभव से, मैंने देखा है कि हंगेरियन ने "कार्गो-कल्ट" प्रोग्रामिंग का उपयोग किया है (अर्थात अन्य कोड इसका उपयोग करता है, इसलिए चलिए इसे सिर्फ इसलिए उपयोग करना जारी रखें) या VB.NET में इस तथ्य के आसपास काम करने के लिए कि भाषा क्या है केस-असंवेदनशील (जैसे Person oPerson = new Personकि आप उपयोग नहीं कर सकते हैं Person person = new Personऔर Person p = new Personबहुत अस्पष्ट है); मैंने उस विशेष मामले में "(" या " Person thePerson = new Personबदसूरत ") के बजाय "the" या "my" को प्रीफ़िक्स करते हुए भी देखा है Person myPerson = new Person

मैं केवल उसी समय जोड़ूंगा जब मैं हंगेरियन का उपयोग ASP.NET नियंत्रण के लिए करता हूं और यह वास्तव में पसंद की बात है। मुझे यह टाइप करने के लिए TextBoxCustomerNameया CustomerNameTextBoxसरल बनाम बहुत ही बदसूरत लगता है txtCustomerName, लेकिन यहां तक ​​कि "गंदा" लगता है। मुझे लगता है कि नियंत्रण के लिए किसी प्रकार के नामकरण सम्मेलन का उपयोग किया जाना चाहिए क्योंकि एक ही डेटा प्रदर्शित करने वाले कई नियंत्रण हो सकते हैं।


13

मैं सिर्फ SQL सर्वर पर ध्यान केंद्रित करूँगा क्योंकि आपने इसका उल्लेख किया है। मुझे टेबल के सामने 'टीबीएल' रखने का कोई कारण नहीं दिखता। आप बस किसी भी tSQL कोड को देख सकते हैं और एक तालिका को अलग कर सकते हैं कि इसका उपयोग कैसे किया जाता है। आप कभी भी Select from stored_procedure.या Select from table(with_param)यूडीएफ की Execute tblTableOrViewNameतरह या एक संग्रहीत प्रक्रिया की तरह नहीं होंगे ।

तालिकाओं को एक दृश्य के साथ भ्रमित किया जा सकता है, लेकिन जब यह आता है कि उनका उपयोग कैसे किया जाता है; कोई अंतर नहीं है, तो बात क्या है? हंगेरियन अंकन आपको एसएसएमएस (तालिका या विचारों के तहत) में इसे देखने का समय बचा सकता है, लेकिन यह इसके बारे में है।

चर एक समस्या पेश कर सकते हैं, लेकिन उन्हें घोषित करने की आवश्यकता है और वास्तव में, आपके घोषित बयान से कितनी दूर आप एक चर का उपयोग करने की योजना बनाते हैं? जब तक आप बहुत लंबी प्रक्रिया नहीं लिख रहे हैं, तब तक कुछ पंक्तियों को स्क्रॉल करना एक सौदे का बड़ा हिस्सा नहीं होना चाहिए। थोड़ा लंबा कोड तोड़ना एक अच्छा विचार हो सकता है।

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


2
@ सर्फर: एक प्राथमिक कुंजी अलग है क्योंकि "पीके" प्रकार नहीं है; "PK_TableName" कहता है "यह TableName के लिए प्राथमिक कुंजी है ", "यह प्रकार PK का एक तालिका नाम नहीं है"। बाकियों के लिए ... ऐसा नहीं लगता कि आप यहाँ तर्क सुन रहे हैं। कृपया इस घृणित अभ्यास का उपयोग करना बंद करें जो कि आज तक सभी कोड की सामूहिक गुणवत्ता को नीचे लाने में बनी हुई है।
एरोनॉट

2
@Aaronaught, आप हंगेरियन नोटेशन के एक पहलू को निर्दिष्ट कर रहे हैं ( en.wikipedia.org/wiki/H ट्वीट्स_not_ )। यह न केवल प्रकार है, बल्कि इसका उपयोग भी करना है। इसलिए प्राथमिक कुंजी के लिए 'pk' के साथ उपसर्ग करना वास्तव में हंगेरियन नोटेशन है। मैं यहाँ तर्क सुन रहा हूँ, लेकिन इसमें कुछ अपवाद हैं (प्राथमिक प्रमुख स्थिति की तरह) जहाँ ऐसा लगता है कि HN फायदेमंद है। शायद शायद नहीं। मैं अभी भी अपने सिर को डो के चारों ओर लपेटने की कोशिश कर रहा हूं और न ही सभी परिदृश्यों के लिए। मैंने आज इसके बारे में काफी कुछ सीखा है और इसने कुछ बेहतरीन विचार पैदा किए हैं।

3
@ सर्फर: यह केवल सही नहीं है। हंगेरियन नोटेशन या तो प्रकार (खराब संस्करण) या प्रकार का एक विशेष उपयोग (कम खराब संस्करण) का वर्णन करता है। पीके न तो है, यह केवल प्रकार के बारे में कुछ का वर्णन नहीं कर रहा है, यह एक व्यवहार का वर्णन कर रहा है । जब मैं एक उम्र के बारे में बात कर रहा हूं, तो यह पूरी तरह से निर्बाध है कि यह एक पूर्णांक होता है, लेकिन जब एक डेटाबेस बाधा के बारे में बात करते हैं, "टेबल एक्स के लिए प्राथमिक कुंजी" बिल्कुल वही है जो महत्वपूर्ण है।
एरोनॉट

4
मुझे आपका दूसरा अंतिम पैराग्राफ पसंद है। हंगेरियन नोटेशन का उपयोग करने के लिए मेरी फर्म का तर्क है "यह हमें जल्दी से यह देखने देता है कि चर क्या वैश्विक हैं और कौन से नहीं हैं।" और फिर आप चर घोषणाओं को देखते हैं और प्रति फ़ाइल 300 चर, मॉड्यूलर (वैश्विक) के लिए कुछ मी *, कुछ ई * स्थानीय स्तर के लिए स्थानीय स्तर पर घोषित होते हैं। "ओह, ऐसा इसलिए है क्योंकि उनका इरादा केवल स्थानीय लोगों के रूप में इस्तेमाल किया जाना है, न कि मॉड्यूलर।" facepalm
corsiKa

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

6

जोड़ने के लिए एक और बात यह है कि, .NET जैसे संपूर्ण ढांचे के लिए आप कौन से संक्षिप्ताक्षर का उपयोग करेंगे? हाँ, यह याद रखना बहुत आसान है कि btnएक बटन का txtप्रतिनिधित्व करता है और एक टेक्स्ट बॉक्स का प्रतिनिधित्व करता है। हालाँकि, आपके मन में किसी चीज़ के लिए क्या है StringBuilder? strbld? किस बारे में CompositeWebControl? क्या आप कुछ इस तरह का उपयोग करते हैं:

CompositeWebControl comWCMyControl = new CompositeWebControl();

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


6

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

SafeString encode(UnsafeString)

और UnsafeString के इंटर्नल तक पहुँचने या कुछ अन्य रूपांतरण फ़ंक्शंस का उपयोग करने की कमी, UnsafeString से एक SafeString तक पहुँचने का एकमात्र तरीका बन जाता है। यदि आपके सभी आउटपुट फंक्शंस हैं, तो केवल SafeString के उदाहरणों को लें, यह एक अन-एस्केप स्ट्रिंग [[शिंगनिगन्स को रूपांतरणों जैसे StringToSafeString (someUnsafeString.Toring) ())] से आउटपुट करना असंभव हो जाता है।

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

C जैसी भाषा में बेशक, आप इस बात से डरे हुए हैं कि एक int एक int है, एक int है, और इसके बारे में आप बहुत कुछ नहीं कर सकते हैं। आप हमेशा स्ट्रक्चर्स के साथ गेम खेल सकते हैं लेकिन यह बहस का विषय है कि इसमें सुधार है या नहीं।

हंगेरियन नोटेशन की अन्य व्याख्या के रूप में, IE, चर के प्रकार के साथ उपसर्ग कर रहा है, यह सिर्फ सादा मूर्खतापूर्ण है और काउंटऑफपीस जैसे कुछ सार्थक के बजाय चर के नामकरण की तरह आलसी प्रथाओं को प्रोत्साहित करता है।


कोई एक .NET या जावा प्रकार का वर्णन करने के लिए कैसे घोषित करेगा " int[]जिसे स्वतंत्र रूप से संशोधित किया जा सकता है लेकिन कभी साझा नहीं किया गया" या " int[]जिसे स्वतंत्र रूप से केवल उन चीजों के बीच साझा किया जा सकता है जो इसे कभी भी संशोधित नहीं करेंगे"? यदि कोई int[]फ़ील्ड fooमानों {1,2,3}को एनकैप्सुलेट करता है, तो क्या {2,2,3}कोई यह जाने बिना एनकैप्सुलेट कर सकता है कि यह किस "प्रकार" का int[]प्रतिनिधित्व करता है? मुझे लगता है कि जावा और .NET बेहतर होता अगर - टाइप-सिस्टम सपोर्ट के अभाव में, वे कम से कम उन प्रकारों को अलग करने के लिए नामकरण सम्मेलन को अपनाते।
सुपरकैट

4

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

गतिशील रूप से टाइप की गई भाषाओं में, यह कभी-कभी मदद कर सकता है, लेकिन मेरे लिए यह अयोग्‍य लगता है। आपने पहले ही अपने कार्यों को सटीक डोमेन / कोडोमन तक सीमित कर दिया था; यदि आपके सभी चरों को नाम संकेतन के साथ नामित किया गया है, तो आप बस पुन: पेश कर रहे हैं कि एक प्रकार की प्रणाली ने आपको क्या दिया होगा। आप पॉलिमॉर्फिक वैरिएबल को कैसे व्यक्त करते हैं जो एक पूर्णांक या सेंट संकेतन में एक स्ट्रिंग हो सकता है? "IntStringX"? "IntOrStringX"? एकमात्र जगह जो मैंने कभी इस्तेमाल की है, जिसमें मैरी नोटेशन का उपयोग असेंबली कोड में किया गया था, क्योंकि मैं कोशिश कर रहा था कि अगर मेरे पास एक प्रकार की प्रणाली थी, तो मुझे वापस मिल जाएगा, और यह पहली चीज थी जिसे मैंने कभी भी कोडित किया था।

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


यह भी सबसे गतिशील टाइप भाषाओं के लिए बहुत बेकार है!
जेम्स एंडरसन

2
आईडीई के लिए यह मैनुअल कोडिंग से भी बदतर है क्योंकि इसका मतलब है कि कोड पूरा होने पर नाटकीय रूप से धीमा हो जाता है। यदि आपके पास 100 पूर्णांक चर हैं, तो टाइपिंग int <alt-space> (उदाहरण के लिए) स्क्रॉल करने के लिए 100 आइटम लाता है। अगर आपको जिसकी आवश्यकता है वह intVeryLongVariableName है तो आपका कोड पूरा होने में समस्या आती है। बिना आयु के, आप केवल बहुत ही <-space> टाइप करेंगे और आपके पास केवल 1 या 2 विकल्प होंगे।
jwenting

3

ऐसे मामले में हमेशा की तरह, मैं अन्य प्रतिभागियों से जवाब पढ़ने से पहले एक उत्तर पोस्ट करूंगा। 

मुझे आपकी दृष्टि में तीन "बग" दिखाई दे रहे हैं: 

1) यदि आप एक चर / पैरामीटर / विशेषता / स्तंभ के प्रकार को जानना चाहते हैं तो आप अपने माउस को घुमा सकते हैं या इसे क्लिक कर सकते हैं और इसे सबसे आधुनिक IDE में प्रदर्शित किया जाएगा। मुझे नहीं पता कि आप कौन से उपकरण का उपयोग कर रहे हैं, लेकिन पिछली बार मुझे ऐसे वातावरण में काम करने के लिए मजबूर किया गया था जो यह सुविधा प्रदान नहीं करता था 20 वीं शताब्दी में, भाषा COBOL थी, उफ़ नहीं, यह फोरट्रान था, और मेरे मालिक समझ में नहीं आया कि मैंने क्यों छोड़ा। 

विकास के चक्र के दौरान 2 / प्रकार बदल सकते हैं। एक 32-बिट पूर्णांक किसी बिंदु पर 64-बिट पूर्णांक बन सकता है, अच्छे कारणों के लिए जो परियोजना की शुरुआत में पता नहीं लगाया गया था। तो, intX को longX में नाम देना या इसे ऐसे नाम के साथ छोड़ना जो गलत प्रकार की ओर इशारा करता है, बुरा कर्म है। 

3) आप जो पूछ रहे हैं वह वास्तव में अतिरेक है। अतिरेक बहुत अच्छा डिजाइन पैटर्न या आदत नहीं है। यहां तक ​​कि मनुष्य बहुत अधिक अतिरेक के लिए अनिच्छुक हैं। यहां तक ​​कि मनुष्य बहुत अधिक अतिरेक के लिए अनिच्छुक हैं। 


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

3

मेरा मानना ​​है कि अय्यर की सख्त जरूरत एक लक्षण हैबहुत सारे वैश्विक चर
का एक लक्षण ... या होने वाले कार्यों को लंबे समय तक रखना संभव नहीं है

यदि आपकी चर परिभाषा दृष्टि में नहीं है, तो आमतौर पर, आपको परेशानी हुई है।
और अगर आपके कार्य कुछ यादगार सम्मेलन का पालन नहीं करते हैं , तो फिर से, बड़ी परेशानी है।

यह ... बहुत अधिक कारण है कि कई कार्यस्थल इसे बाहर निकालते हैं, मुझे लगता है।

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

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

( उदाहरण "क्या चर safeFoobarको SQL क्वेरी में इंजेक्ट करने के लिए एक हरे रंग की रोशनी है?
- जैसा कि इसे कहा जाता है safe, हाँ")

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


2

मुझे लगता है कि हंगेरियन नोटेशन का उपयोग नहीं करने के कारणों को अन्य पोस्टरों द्वारा अच्छी तरह से कवर किया गया है। मैं उनकी टिप्पणियों से सहमत हूं।

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


मुझे अक्सर ऐसा लगता है जब मेरे पास आईडी की एक तालिका होती है। अगर मैं इस TABLE SomeStringById(int somestringId, varchar somestring)पर सूचकांक भी तार्किक रूप से होगा, SomeStringByIdलेकिन यह एक टकराव का कारण बनता है। इसलिए मैं इसे बुलाता हूं idx_SomeStringById। फिर, सूट का पालन करने के लिए, मैं idx_SomeStringByValueसिर्फ इसलिए करूंगा क्योंकि यह मूर्खतापूर्ण है कि एक idx_पर और दूसरे पर नहीं।
corsiKa

1

इसका कारण यह है कि इसे टाला जाता है, क्योंकि सिस्टम DR का उल्लंघन करता है (उपसर्ग ठीक उसी प्रकार है जो कंपाइलर और (एक अच्छा) IDE प्राप्त कर सकता है)

एप्लिकेशन (वेरिएबल का स्क्रैचमाऊस स्क्रीन पर कुल्हाड़ी मारना है) के उपयोग के साथ मैरी ओटोह उपसर्ग करता है यह एक इंट, शॉर्ट, लॉन्ग या यहां तक ​​कि एक कस्टम प्रकार भी हो सकता है (टाइपफीड आपको आसानी से इसे बदलने की अनुमति देगा)

सिस्टम की गलतफहमी है कि क्या एक सबसे अच्छा अभ्यास है


2
मुझे असहमत होना है - हंगेरियन को "सर्वोत्तम अभ्यास" के रूप में नष्ट कर दिया, यह है कि यह कभी भी सर्वोत्तम (या अच्छा) अभ्यास के करीब नहीं था।
जेरी कॉफिन

2
@ हाइलम: मैंने लेख और सिमोनी के मूल पेपर को देखा है और कोड पढ़ा है। हर तरह से आप इसे देखते हैं, यह एक बुरा विचार है जिसे कभी भी दिन का प्रकाश नहीं देखना चाहिए।
जेरी कॉफ़िन

1
यह जरूरी नहीं कि गतिशील भाषा में DRY का उल्लंघन हो; यह सिर्फ अविद्या है। जरूरी नहीं कि DRY हमेशा अच्छी हो; पूर्व: सी मैक्रोज़।
लॉन्गपोक

3
IMO ने "हंगेरियन" को नष्ट कर दिया, यह तथ्य यह है कि वर्णनात्मक नामों का उपयोग करने की तुलना में "इरादा" भी उपयोगी नहीं है , हालांकि निष्पक्ष होने के लिए जब हंगेरियन बनाया गया था तो पठनीय कोड होने के लिए कोई आंदोलन नहीं था ...
वेन मोलिना

1
@Wayne M: "वर्णनात्मक नाम" कहना आसान है जब संकलक अनिवार्य रूप से आपको एक चर नाम के लिए एक निबंध का उपयोग करने की अनुमति देगा। जब पहचानकर्ता नामों की लंबाई वास्तव में एक कम, काफी मनमाना मूल्य तक सीमित थी (मुझे लगता है कि एक सामान्य सीमा आठ या दस वर्ण थी जो बहुत पहले नहीं थी; मुझे याद है कि बोरलैंड टर्बो सी 2 के पास एक कॉन्फ़िगरेशन विकल्प भी था । एक पहचानकर्ता नाम की अधिकतम लंबाई!), एक नाम में उपयोगी जानकारी को एन्कोडिंग सिर्फ एक छोटा सा
छल था

1

मान लें कि हमारे पास इस तरह की विधि है (C # में):

int GetCustomerCount()
{
    // some code
}

अब कोड में हम इसे इस तरह कहते हैं:

var intStuff = GetCustomerCount();
// lots of code that culminates in adding a customer
intStuff++;

पूर्णांक हमें बहुत ज्यादा नहीं बताता है। मात्र तथ्य यह है कि कुछ एक int है हमें यह नहीं बताता कि इसमें क्या है। अब मान लेते हैं, इसके बजाय, हम इसे इस तरह कहते हैं:

var customerCount = GetCustomerCount();
// lots of code that culminates in adding a customer
customerCount++;

अब हम देख सकते हैं कि चर का उद्देश्य क्या है। अगर हमें पता है कि यह एक इंट है तो क्या फर्क पड़ेगा?

हालाँकि, हंगेरियन का मूल उद्देश्य आपको कुछ इस तरह से करना था:

var cCustomers = GetCustomerCount();
// lots of code that culminates in adding a customer
cCustomers++;

यह तब तक ठीक है जब तक आप जानते हैं कि c का मतलब क्या है । लेकिन आपके पास उपसर्गों की एक मानक तालिका होनी चाहिए, और सभी को उन्हें जानना होगा, और किसी भी नए लोगों को आपके कोड को समझने के लिए उन्हें सीखना होगा। जबकि customerCountया countOfCustomersपहली नज़र में बहुत स्पष्ट है।

हंगरी का Option Strict Onअस्तित्व में होने से पहले VB में कुछ उद्देश्य था, क्योंकि VB6 और पूर्व में (और VB .NET में Option Strict Off) VB के साथ सामंजस्य होगा, इसलिए आप ऐसा कर सकते हैं:

Dim someText As String = "5"
customerCount = customerCount + someText

यह बुरा है, लेकिन संकलक आपको ऐसा नहीं बताएगा। इसलिए यदि आपने हंगेरियन का उपयोग किया है, तो कम से कम आपके पास कुछ संकेतक होगा जो हो रहा था:

Dim strSomeText As String = "5"
intCustomerCount = intCustomerCount + strSomeText  // that doesn't look right!

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


1

मुझे इसके खिलाफ बहुत अच्छे तर्क मिले, लेकिन एक मैंने नहीं देखा: एर्गोनॉमिक्स।

पूर्व समय में, जब आपके पास स्ट्रिंग, इंट, बूल और फ्लोट होते थे, तो पात्र sibf पर्याप्त होते थे। लेकिन स्ट्रिंग + शॉर्ट के साथ, समस्याएं शुरू होती हैं। उपसर्ग के लिए पूरे नाम का उपयोग करें, या स्ट्रिंग के लिए str_name? (जबकि नाम लगभग हमेशा तार होते हैं - वे नहीं हैं?) स्ट्रीट क्लास के साथ क्या है? नाम लंबे और लंबे हो जाते हैं, और यहां तक ​​कि अगर आप CamelCase का उपयोग करते हैं, तो यह बताना मुश्किल है कि प्रकार-उपसर्ग कहां समाप्त होता है और चर-नाम कहां से शुरू होता है।

 BorderLayout boderLayoutInnerPanel = new BorderLayout ();
 panelInner.addLayout (borderLayoutInnerPanel);

ठीक है - आप अंडरलाइन का उपयोग कर सकते हैं, यदि आप उन्हें पहले से किसी और चीज के लिए उपयोग नहीं करते हैं, या कैमेलकेस का उपयोग करते हैं यदि आपने अंडरलाइन का उपयोग किया है:

 BorderLayout boderLayout_innerPanel = new BorderLayout ();
 panel_inner.addLayout (borderLayout_innerPanel);

 Border_layout boder_layoutInner_panel = new Border_layout ();
 panelInner.add_layout (border_layoutInner_panel);

यह राक्षसी है और यदि आप इसे फलस्वरूप करते हैं, तो आपके पास होगा

 for (int iI = 0; iI < iMax-1; ++iI)
     for (int iJ = iI; iJ < iMax; ++iMax) 
          int iCount += foo (iI, iJ); 

या तो आप तुच्छ मामलों के लिए बेकार उपसर्गों का उपयोग करने में समाप्त हो जाएंगे, जैसे कि लूप-चर या count। आपने हाल ही में एक काउंटर के लिए छोटा या लंबा कब इस्तेमाल किया? यदि आप अपवाद बनाते हैं, तो आप अक्सर समय को ढीला कर देंगे, एक उपसर्ग की आवश्यकता के बारे में सोच रहे हैं या नहीं।

यदि आपके पास बहुत सारे चर हैं, तो वे सामान्य रूप से एक ऑब्जेक्ट ब्राउज़र में समूहीकृत हो जाते हैं जो आपके आईडीई का हिस्सा है। अब अगर 40% int_ के लिए i_ के साथ शुरू होता है, और स्ट्रिंग के लिए s_ के साथ 40%, और वे वर्णानुक्रम में सॉर्ट किए जाते हैं, तो नाम का महत्वपूर्ण भाग खोजना मुश्किल है।


1

एक जगह जहां मैं अभी भी नियमित रूप से हंगेरियन या अनुरूप प्रत्ययों का उपयोग करता हूं, संदर्भों में है जहां एक ही अर्थ डेटा दो अलग-अलग रूपों में मौजूद है, जैसे डेटा रूपांतरण। यह उन मामलों में हो सकता है जहां माप की कई इकाइयां हैं, या जहां कई रूप हैं (जैसे, स्ट्रिंग "123" और पूर्णांक 123)।

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

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

"बस एक IDE में मंडराना" है नहीं केवल एक कारण - एक कारण हंगेरी का उपयोग नहीं करने के लिए कुछ लोगों को यह उपयोगी नहीं मिल सकती है। आपका माइलेज अलग हो सकता है।

जब चर प्रकार मूर्खतापूर्ण होते हैं तो हंगरी एक महत्वपूर्ण रखरखाव बोझ लगाता है - आप चर प्रकार कितनी बार बदलते हैं? इसके अलावा, चर नाम बदलना आसान है:

सभी घटनाओं का नाम बदलने के लिए बस IDE का उपयोग करें। -गैंडर को जवाब देते हुए गैंडर

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.