क्या आप चर प्रकारों के संक्षिप्त नाम के साथ चर नाम उपसर्ग करते हैं? (हंगेरियन नोटेशन) [बंद]


37

मेरी वर्तमान नौकरी में, कोई कोडिंग दिशानिर्देश नहीं हैं। हर कोई बहुत तरह से कोड चाहता है। जो ठीक है, चूंकि कंपनी छोटी है।

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

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

तो, आप हंगेरियन नोटेशन के बारे में कैसा महसूस करते हैं? क्या तुम इसका इस्तेमाल करते हो? क्यूं कर?



7
आप किस प्रोग्रामिंग भाषा का उपयोग कर रहे हैं?
लैरी कोलेमन

3
वास्तव में यह ठीक नहीं है - आपके पास एक कोडिंग मानक (औपचारिक या अन्यथा) होना चाहिए, मेरी राय में यह कभी ठीक नहीं है ... लेकिन अन्य लोग असहमत हो सकते हैं।
मूर

@ लॉरी: हम ज्यादातर सी और सी ++ का उपयोग कर रहे हैं, यहां और वहां एसेम्बलर और लुआ के एक smattering के साथ।
बस्तिब

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

जवाबों:


77

जब ज्यादातर लोग "हंगेरियन नोटेशन" कहते हैं, तो वे वास्तव में " सिस्टम हंगरी " के बारे में बात कर रहे हैं ।

सिस्टम हंगेरियन पूरी तरह से बेकार है और इसे टाला जाना चाहिए। इसके नाम में चर के प्रकार को एनकोड करने की आवश्यकता नहीं है । हालाँकि, सिस्टम हंगेरियन वास्तव में मूल , "वास्तविक" हंगेरियन: एप्स हंगेरियन की गलतफहमी है ।

ऐप्स हंगेरियन में, आप "नाम" को चर नाम में एनकोड नहीं करते हैं, आप चर के "प्रकार" को एनकोड करते हैं। तो नहीं nWidth, लेकिन pxWidthया emWidth("पिक्सेल में चौड़ाई" या "ईएमएस में चौड़ाई" क्रमशः के लिए)। नहीं strNameबल्कि sNameया usName("सुरक्षित नाम" या "असुरक्षित नाम" के लिए क्रमशः - उपयोगकर्ताओं से इनपुट स्वीकार करते समय उपयोगी: असुरक्षित स्ट्रिंग्स)।

निजी तौर पर, मैं आमतौर पर या तो परेशान नहीं करता। जब तक मैं कुछ ऐसा कर रहा हूं जो स्पष्ट रूप से मूल्य के "प्रकार" को परिवर्तित कर रहा है (उदाहरण के लिए, मैंने अतीत में "px" और "em" उपसर्ग का उपयोग किया है क्योंकि यह गलत जैसी गलतियां करता pxArea = emWidth * emHeightहै)।

यह भी देखें, जोएल का लेख, " गलत कोड देखना गलत है ।"


2
इस विषय पर सिमोनी के लेखन की जाँच करें: वह हंगेरियन का मूल प्रवर्तक है, और उसका संस्करण वह है जो उपयोगी है। msdn.microsoft.com/en-us/library/aa260976(v=vs.60).aspx
माइकल

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

1
उपयोगकर्ता इनपुट के साथ काम करने वाले कोड में, मुझे इसका डेटा उपसर्ग के लिए उपयोगी लगता है rawजैसेrawUsername
zzzzBov

1
@ दूसरा विकल्प एक जोरदार टाइप्डिफ
jk होगा।

1
@ जेबीआर: क्या आपने वास्तव में जवाब पढ़ा है? "ऐप्स हंगरी" में, sहै के लिए stringया कुछ और, लेकिन "सुरक्षित" के लिए (या मैं भी "सुरक्षित स्ट्रिंग" सुना है)।

31

सर्वनाम।


6
मुझे मुसकराया ... पदयात्रा की, लेकिन "टू" एक दिखावा है, न कि एक असीम। "पढ़ने के लिए" एक असीम है।
DrAl

@ निश्चित रूप से, यह विनम्र रजिस्टर में था, व्याकरण की सनक नहीं: डी
स्मिरकिंगमैन

1
वह कमाल था, जिससे मुझे हंसी आई। :)
Corv1nus

26

पहले तो:

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

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

अब हंगेरियन संकेतन पर:

हालांकि इसका उपयोग एक आधुनिक IDE के साथ किया गया था, जो IntelliSense प्रकार के व्यवहारों का समर्थन करता है, इसके नाम में चर के प्रकार को शामिल करना आवश्यक नहीं है। यह जानकारी आपको अन्य तरीकों से उपलब्ध है। इससे भी बदतर यह कोड को पढ़ने के लिए कठिन बना सकता है यदि आपको भविष्य में चर के प्रकार को बदलना है।


21

इसका उपयोग न करें। यह बेमानी है और कोड को पढ़ना मुश्किल बनाता है।


8
यह "बेमानी" से भी बदतर है। कुछ जटिल स्थितियों के लिए, सही होना मुश्किल है। विशेष रूप से, आपके द्वारा अपने ऐप में परिभाषित प्रत्येक वर्ग को एक संक्षिप्त नाम की आवश्यकता होती है। 20 या इतनी कक्षाओं को परिभाषित करने के बाद, आप एक-अक्षर के संक्षिप्त विवरण से बाहर हो जाते हैं। अब क्या? एक अक्षर और दो अक्षर का मिश्रण? डेटा संरचना के एक तत्व के जटिल संदर्भों के बारे में क्या? पूर्णांक से तार तक मैपिंग के लिए सूचियों के मैपिंग के सरणी को इंगित करें? इसका संक्षिप्त नाम कैसे सहायक होगा?
एस.लॉट

13

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

सिस्टम हंगेरियन

मैं जो बता सकता हूं, उससे सिस्टम हंगेरियन का उपयोग एम्बेडेड क्षेत्र में बहुत अधिक किया जा सकता है। पीसी अनुप्रयोगों में, कंपाइलर बहुत सारे मुद्दों (जैसे) तार, पूर्णांक और फ्लोटिंग पॉइंट वैल्यू के बीच के अंतर से निपटेगा। एक गहराई से एम्बेडेड प्लेटफ़ॉर्म पर, आप अक्सर 8-बिट अहस्ताक्षरित पूर्णांकों, 16-बिट हस्ताक्षरित पूर्णांक आदि के बीच के अंतर के बारे में चिंतित होते हैं। कंपाइलर (या यहां तक ​​कि लागू किए गए MISRA नियमों के साथ एक प्रकार का वृक्ष) हमेशा इन पर नहीं उठाता है। इस मामले में u8ReadIndex, जैसे चर नाम , s16ADCValueसहायक हो सकते हैं।

ऐप्स हंगेरियन

एप्लिकेशन हंगेरियन के निश्चित फायदे हैं जब यह पीसी / वेब अनुप्रयोगों के लिए आता है, उदाहरण के लिए 'असुरक्षित' तार और 'सुरक्षित' तार के बीच एक दृश्य अंतर की पेशकश (यानी जो एक उपयोगकर्ता द्वारा दर्ज की गई है और जो आंतरिक संसाधनों से बच गए हैं या पढ़े गए हैं या जो भी हो )। संकलक को इस भेद का कोई ज्ञान नहीं है।

क्या बात है?

हंगेरियन (सिस्टम या एप्स) का उपयोग गलत कोड को गलत बनाने के बारे में है

यदि आप एक असुरक्षित स्ट्रिंग को कुछ बच के बिना एक सुरक्षित स्ट्रिंग में सीधे कॉपी कर रहे हैं, तो यह गलत होगा यदि आप एप्स हंगेरियन का उपयोग करते हैं।

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

इन दोनों स्थितियों में (Apps / Systems) हंगेरियन नोटेशन औपचारिक कोड समीक्षा को तेज करने के लिए जाता है क्योंकि चर के प्रकार पर कम जिक्र होता है।

संपूर्ण

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


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

9

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

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

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

यहाँ F # में एक सरल उदाहरण दिया गया है:

[<Measure>] type m
[<Measure>] type ft

let someLength      = 48.15<m>
let someOtherLength = 16.2342<ft>

someLength + someOtherLength
// someLength + someOtherLength
// -------------^^^^^^^^^^^^^^^
// error FS0001: The unit of measure 'ft' does not match the unit of measure 'm'.

देखो, मा, कोई हंगेरियन नहीं!

अगर मैं थे बजाय यहां प्रकार के हंगेरी संकेतन, उपयोग करने के लिए है कि मेरी मदद नहीं होता एक बिट:

let mSomeLength       = 48.15
let ftSomeOtherLength = 16.2342

mSomeLength + ftSomeOtherLength
// > val it : float = 64.3842

संकलक इसे सीधे जाने दें। मैं अब एक मानव पर भरोसा करने के लिए भरोसा कर रहा हूं कि अनिवार्य रूप से एक त्रुटि क्या है। क्या ऐसा नहीं है कि एक प्रकार की चेकर किसके लिए है?

इससे भी बेहतर, फ्रिंक प्रोग्रामिंग भाषा का उपयोग करना :

someLength      = 48.15m
someOtherLength = 16.2342ft

someLength + someOtherLength
// 53.09818416 m (length)

// Wanna know the answer in a good old fashioned American unit?
someLength + someOtherLength -> yd
// 58.06888031496062992

// Are you an astrophysicist?
someLength + someOtherLength -> parsec
// 1.7207949554318336148e-15

// ... or a fundmentalist Christian who refuses to use units invented 
// less than 2000 years ago?
someLength + someOtherLength -> biblicalcubits
// 95.893563822870765006

तो, सारांश में: मुझे हंगेरियन नोटेशन पसंद नहीं है। आपको इसका उपयोग कभी नहीं करना चाहिए।

कहा जा रहा है, मुझे लगता है कि हंगेरियन नोटेशन का उपयोग करना एक अच्छा विचार है। रुको क्या?

हाँ! इस विशेष मामले में , आपने उल्लेख किया है:

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

लेकिन वह यह है कि ठीक ही समझदार उपयोग के मामले के लिए हंगेरी संकेतन!


पुनश्च: मैं पूरी निष्ठा से फ्रिंक को देखने की सलाह देता हूं। इसके मैनुअल में अब तक के सबसे भयानक गोज़ चुटकुले हैं। यह भी एक बहुत अच्छी भाषा है :-)


अगर मैं कर सकता तो मैं इसे 50 बार वोट करूंगा।
लैरी कोलेमन

1
बहुत दिलचस्प तर्क! मैं अपने मौजूदा प्रोजेक्ट में बस यही कोशिश कर सकता हूं। typedef meter float...
बस्तरिब

6

यह एक वस्तु उन्मुख भाषा में समझ में नहीं आता है - सब कुछ एक प्रकार है जो इसे उपयोग करने की कोशिश करते समय स्पष्ट है।


6

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

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

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


1
दरअसल, अच्छे IDE (या प्लगइन्स) में आमतौर पर बहुत शक्तिशाली रीफैक्टरिंग क्षमताएं होती हैं जो आसानी से परिवर्तनशील नामों को बदल सकती हैं।
बस्तीबाई

4
समझ में आया, लेकिन नाम परिवर्तन के लिए संस्करण नियंत्रण में अतिरिक्त शोर या तो चीजों की मदद नहीं करता है। मान लीजिए कि जोड़ा गया मूल्य रखरखाव के ओवरहेड को सही नहीं ठहराता है।
बेरिन लोरिट्श

भाषा पर निर्भर करेगा और साथ ही कुछ लोगों के पास सीधे टाइप किए गए UoM या stongly टाइप किए गए टाइफेड के लिए सीधा समर्थन है
jk।

6

मत्स्यावरोध नहीं!

हंगेरियन नोटेशन या किसी अन्य नोटेशन का उपयोग न करें। प्रोग्रामर के रूप में, हमें अपने चर नामों के लिए "नोटेशन" का उपयोग नहीं करना चाहिए।

हमें अपने चर को अच्छी तरह से नाम देना चाहिए :

  • बहुत सामान्य नामों से बचें। यह zतब नाम न दें जब यह एक वर्ग चर नामांकित वस्तु का प्रतिनिधित्व करता है, कहते हैं, एक फोन बिल। इसे बुलाओ phoneBillया PhoneBill
  • बहुत विशिष्ट नामों से बचें। जब अतिरिक्त जानकारी के बिना कुछ स्पष्ट होता है तो उसमें शामिल नहीं होते हैं। यदि यह एक स्ट्रिंग के पात्रों के माध्यम से लूपिंग के लिए सिर्फ एक स्ट्रिंग इंडेक्स चर है, और आप इसे केवल एक बार फ़ंक्शन MyFunc में उपयोग करते हैं, तो पृथ्वी पर आप इसे कभी क्यों कहेंगे MyFuncTempStringCharacterIndex? यह एक दुखद मजाक है। आप इसे पसंद करें Posया चाहे iतो कॉल करें । संदर्भ में, अगला प्रोग्रामर आसानी से समझ जाएगा कि इसका क्या मतलब है।

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

जैसा कि अन्य उत्तरदाताओं ने कहा है, यह यह संकीर्ण मामला है जिसने "एप्स हंगेरियन" की शुरुआत की, खिड़की के सापेक्ष माप rwTabPositionऔर दस्तावेज़ के सापेक्ष अंतर करने के लिए rdTabPosition। लेकिन एक आवेदन में जो दस्तावेज़ के सापेक्ष सब कुछ करता है, किसी भी अतिरिक्त क्रॉफ्ट को न जोड़ें! वास्तव में, Jörg W Mittag के विचार का उपयोग वास्तविक वास्तविक प्रकार बनाने के लिए क्यों नहीं किया गया? फिर आप संभवतः चीजों को मिला नहीं सकते।

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

vrbDo सलाह vrbuse nouH अनुवाद संज्ञा उद्धरण cnjor adjany adjother संज्ञा। प्रेप्स नूप्रोग्रामर्स, प्रवे व्रबशोल्ड वर्न्यू नोब्यूसिंग "संज्ञा" प्रॉपोर प्रॉप एडज्वरेबल संज्ञा।

द्वारा जोड़ने जानकारी, मैंने बनाया है कि एक पूरा दर्द को पढ़ने के लिए।

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

चर नाम के रूप में रखें कम संभव के रूप में, सार्थक आवश्यक के रूप में, और हमेशा स्पष्ट


यह लगभग हमारे मानक हैं। अंतर केवल इतना है कि हम पास्कल केस को पसंद करते हैं जब चीजों का नामकरण किया जाता है ताकि पूंजीकरण निरंतर हो।
DForck42

5

किसी पहचानकर्ता का उद्देश्य उसके प्रकार से अधिक महत्वपूर्ण है। यदि आप अपने कार्यक्रमों में पहचानकर्ताओं के लिए वर्णनात्मक नाम का उपयोग करते हैं, तो आपको हंगेरियन नोटेशन का उपयोग करने की आवश्यकता नहीं है। isConnectedहमेशा अधिक पठनीय और समझने में आसान होता है boolConnected


2
मैं पूरी तरह से सहमत हूं! इसे वे 'सिस्टम हंगेरियन' के विपरीत 'ऐप हंगेरियन' कहते हैं।
बस्तीबाई

@bastibe: नहींं, इसे वे वर्णनात्मक नाम कहते हैं। एप्लिकेशन हंगेरियन संक्षिप्त पर निर्भर करता है।
जैक्सबी

2

जब मैं C ++ प्रोग्रामर था, तब हमने हंगेरियन का उपयोग किया और यह बहुत अच्छा था। आप घोषणा के बिना खोज के चर (fe BSTR, CString, LPCTSTR, या char *) देख सकते हैं। उन दिनों में, आप घोषणा करके खोज करेंगे:

  1. ctrl-घर
  2. Ctrl-F
  3. चर का नाम
  4. दर्ज

इसलिए यह काफी मायने रखता है। लेकिन कहीं 2000 के आसपास, कुछ चीजें हुईं:

  • एडिटर एक टूलटिप के रूप में वेरिएबल प्रकार को प्रदर्शित करने के लिए पर्याप्त बुद्धिमान बन गए
  • संपादकों के पास "घोषणा के लिए जाना" शॉर्टकट था, और वापस ब्राउज़ करने का एक त्वरित तरीका था
  • C ++ का उपयोग कम किया गया था, और अधिकांश अन्य भाषाओं में कम परिवर्तनशील प्रकार होते हैं। उदाहरण के लिए, C # में, आपको पूरा यकीन lastNameहै कि यह एक है System.String, क्योंकि केवल एक स्ट्रिंग क्लास है।

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


2

मुझे बस आयु संकेतन से नफरत है, मैं चर नामों को परिसीमित करने के लिए अंडरस्कोर का उपयोग करना पसंद करता हूं।

उसके शीर्ष पर, जब आप अपने चर नाम की भीख पर पहला अक्षर इस प्रकार लिखते हैं: फ्लोट फेलोसिटी; vect vDirection; स्ट्रिंग ** ppszWord;

स्वत: पूर्णता उन सभी को छाँटती है, और आप जो चाहते हैं उसे पाने में परेशानी होती है, और लोग जो बेहतर समझते हैं उसका उपयोग करते हैं, और यह अब कोई संकेत नहीं है।

जब मैं चर के बारे में बहुत वर्णनात्मक होने की जरूरत है, तो मैं ThingsLikeThat लिखना पसंद करता हूं, क्योंकि यह अंतरिक्ष बचाता है और तथ्य यह है कि कैप हैं यह अधिक पठनीय बनाता है।

मैं आमतौर पर क्या करता हूं, पहले अक्षर के साथ अपने तरीके और कक्षाओं का नाम है अपरकेस, और चर नामों के लिए लोअरकेस, और चर नामों के लिए एक अंडरस्कोर (मुझे यह अंतिम उपयोगी लगता है)।

गंभीरता से मैं लोगों को उन नियमों की परवाह करना पसंद करता हूं: प्रासंगिक स्थानों के साथ अल्पविराम, अंकगणित और ब्रेसिज़ का उपयोग करें:

void f(int a, char b);
int a = b + 4 / (3 + 4);

प्रत्येक पंक्ति में 80 से अधिक चार्ट, या AT MOST 90 चार्ट, फ़ंक्शन या लंबे समय के लिए बहु-लाइन तर्क का उपयोग नहीं करते हैं if:

if
(
    checkthat(a, b) == checkthis(b, d) &&
    checkthat(d, b) == checkthis(v, d)
)

1

सबसे सहमत हूं, यह एक पुरानी शैली है।

आधुनिक आईडीई के साथ, एक चर पर एक त्वरित होवर आपको प्रकार दिखाता है।


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

आप गलत हैं !!!!! ;) निष्पक्ष बिंदु, मैं अभी भी हंगेरियन उपयोगकर्ता नहीं होगा!
उल्लू
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.