2013-08-17 12 views
5

मैं वर्तमान में learncpp.com के सी ++ ट्यूटोरियल्स के माध्यम से जा रहा हूं और मैं देख रहा हूं कि उनके परिवर्तनीय नामकरण प्रवृत्ति ने उन्हें चर के चर के लिए "एन" उपसर्ग (यानी int nValue) और "ch" उपसर्गों के साथ int चर का नाम दिया है (यानी चार choperation)। क्या यह ऐसा उद्योग है जो उद्योग में आम है कि मुझे अब आदत के रूप में बनाना चाहिए?सी ++ में int या char चर नामकरण करते समय "n" या "ch" उपसर्ग सामान्य उपसर्ग हैं?

+0

आप परिवर्तनीय नामों के हंगेरियन नोटेशन के व्युत्पन्न के बारे में बात कर रहे हैं, और ईमानदारी से यह वास्तव में तब तक कोई फर्क नहीं पड़ता जब तक कि आप सुसंगत न हों और कोड * पठनीय * हो। – WhozCraig

+1

दरअसल 'n' और' ch' उपसर्ग _Systems_ हंगरी हैं, _Apps_ हंगरी नहीं। बहुत सारे लोग हैं, जिनमें कई महान प्रोग्रामर और गुरु शामिल हैं, जो सिस्टम हंगेरियन के खिलाफ बहुत दृढ़ता से बहस करते हैं, भले ही कोड "सुसंगत" हो। यहां तक ​​कि जो लोग हंगेरियन नोटेशन कहते हैं, वे आज भी काफी कहते हैं कि यह ऐप्स है, * नहीं * सिस्टम, हंगेरियन स्वीकार्य है। [हंगेरियन नोटेशन के लिए विकिपीडिया पेज] पर विवरण (http://en.wikipedia.org/wiki/Hglish_notation)। –

+0

मुझे लगता है कि यह एक अच्छा पठन है: http://herbsutter.com/2008/07/15/hglish-notation-is-clearly-goodbad/ –

उत्तर

11

क्या यह ऐसा कुछ है जो उद्योग में आम है?

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

यह दूसरों द्वारा व्यापक रूप से उपयोग किया जाता है, माइक्रोसॉफ्ट (संभवतया) के बाद लंबे समय से एहसास हुआ कि यह व्यर्थ था और advised against its use, संभवतः यह विश्वास में कि माइक्रोसॉफ्ट की आदतों को अनुकरण करने से उनकी सफलता भी अनुकरण हो सकती है। यह आज भी कभी-कभी देखा जाता है, जो लोग आदतें विकसित करते हैं और कभी भी उनकी उपयोगिता पर सवाल नहीं करते हैं, और उन कंपनियों द्वारा जो सॉफ्टवेयर के ऊपर स्टाइल गाइड को प्राथमिकता देते हैं।

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

मुझे अब एक आदत के रूप में बनाना चाहिए?

यह केवल कोड को पढ़ने के लिए कठिन बनाता है, और अगर आप एक चर के प्रकार को बदलते समय टैग को अपडेट करना भूल जाते हैं तो भ्रामक बनाते हैं। आपको स्पष्ट, पठनीय कोड लिखने की आदत विकसित करनी चाहिए, न कि रहस्यमय दौड़ने के साथ इसे छिड़काव करना।

अस्वीकरण: माइक्रोसॉफ्ट के बारे में संक्षिप्त टिप्पणियां ऐतिहासिक संदर्भ देने का इरादा रखती हैं और माइक्रोसॉफ्ट के नीति निर्णयों का एक अधिकृत खाता बनने का इरादा नहीं है; विशेष रूप से वाक्यांश "[माइक्रोसॉफ्ट] का एहसास हुआ [यह] व्यर्थ था" का मतलब है "[माइक्रोसॉफ्ट के कुछ लोगों] को एहसास हुआ [चर्चा के तहत विषय, अधिकांश संदर्भों में आधुनिक सी ++ में अनावश्यक प्रकार के टैग का उपयोग करके] व्यर्थ था" नहीं (जैसा कि टिप्पणीकर्ता ने पढ़ा है) "[माइक्रोसॉफ्ट की पूरी तरह से] एहसास हुआ [चर टैगिंग के सभी उपयोग] व्यर्थ था"। सभी राय मेरी हैं, और अपूर्ण ज्ञान पर आधारित हो सकती है।

+0

आप "माइक्रोसॉफ्ट को एहसास हुआ कि यह व्यर्थ था" तर्क के लिए बिल्कुल संदर्भ नहीं दे रहा है। जबकि मैं सी ++ के साथ किसी प्रकार की हंगेरी नोटेशन का उपयोग करने का सुझाव नहीं देना चाहूंगा, यह सी इंटरफ़ेस (जैसे विंडोज एपीआई) से निपटने पर निश्चित रूप से ** बहुत ** की सहायता करता है। मैं एक मान के लिए एक असंबद्ध औपचारिक आकार पैरामीटर जो इंगित करता है कि यह बाइट्स ('cb') या वर्णों की संख्या (' cch') में आकार है या नहीं। – IInspectable

+1

@IInspectable: मुझे नहीं लगता था कि एक संदर्भ आवश्यक होगा, लेकिन [यहां एक है] (http://msdn.microsoft.com/en-us/library/ms229045.aspx)। उद्धरण (उनके जोर के साथ): "** ** हंगेरियन नोटेशन का उपयोग न करें।" –

+1

उम .... वह .NET है, जिसे दृढ़ता से सी ++ के रूप में टाइप किया गया है। जिस माइक्रोसॉफ्ट के बारे में आप बात कर रहे थे वह बीस या तीस साल पहले माइक्रोसॉफ्ट है, कथित तौर पर एहसास हुआ कि सी इंटरफेस के लिए पैरामीटर नामों में अर्थपूर्ण जानकारी एम्बेड करना गलती है। मैं उस तरह के संदर्भ के बारे में सोच रहा था। – IInspectable

2

हाँ, वे आम (esp। विंडोज संबंधित परियोजनाओं में) कर रहे हैं

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

आपके द्वारा उल्लिखित नामकरण शैली को Hungarian style के रूप में जाना जाता है, जिसका उपयोग आमतौर पर विंडोज संबंधित परियोजनाओं में किया जाता है। हंगेरी शैली में, चर ऊंट मामले (जैसे, केमलकेस) में स्वरूपित और उनके दायरे और प्रकार से लगी होती हैं:

[scope prefix]_[variable type][actual variable name in camel-cased style] 

उदाहरण के लिए:

m_nMemberInteger 

एक पूर्णांक है (करने के लिए इसे n उपसर्ग अनुसार), इसके अतिरिक्त, यह एक सदस्य चर (इसके उपसर्ग m_ के अनुसार) कुछ संरचना/वर्ग के लिए है, और आप उपरोक्त लिंक में हंगरी शैली में उपयोग किए गए स्कोप की पूरी सूची और उपसर्गों को टाइप कर सकते हैं।

हालांकि, linux आधारित परियोजनाओं में, आप आमतौर पर लोगों को विभिन्न कोडिंग शैलियों का उपयोग कर पाएंगे (उदाहरण के लिए, Google c++ coding style) है, जो केवल छोटे मामलों का उपयोग करता है और _ को रेखांकित उनके चर नाम है।

0

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

-1

जैसा कि कुछ पहले से ही टिप्पणी कर चुके हैं, यह हंगेरी नोटेशन के संस्करण की तरह दिखता है।

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

  1. आप वैरिएबल प्रकार बदलते हैं, तो नाम है, जो कुछ बहुत ही खतरनाक अंतर्निहित रूपांतरण का कारण बन सकती बदलना होगा ऐसा मत करो।

  2. यह स्पष्ट और लक्ष्य विशिष्ट चर नाम जिसके फलस्वरूप मेंटेनर बलों सिर्फ नाम स्पष्ट प्राकृतिक भाषा में सौंपा पढ़ने के बजाय अपना हंगेरी स्टाइल चर नाम डिकोड करने के लिए प्रोत्साहित नहीं करता है।

  3. आईडीई में परिवर्तनीय नाम पूर्णता व्यावहारिक रूप से बेकार हो जाती है।

  4. यह बदसूरत लग रहा है (मैं क्या मतलब है के उदाहरण के लिए, Win32 एपीआई को देखो।

  5. अक्सर अस्पष्टता होती है, खासकर यदि आपके पास कई कस्टम डेटाटाइप के पॉइंटर्स हैं।

शैली का एक बहुत अच्छी चर्चा के लिए कारणों की एक अधिक गहन कवरेज के लिए the Stanford CS106B guide to variable names देखते हैं।

इसके अलावा, The Wikipedia page on Hungarian Notation

0

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

void MyClass::myMethod(const int& iInput, int& oOutput, int &ioInputAndOutput) 
{ 
    oOutput = ioInputAndOutput + mMemberData + iInput; 
    ioInputAndOutput *= 2; 
} 

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

संबंधित मुद्दे