मैंने बहुत अधिक सी # और सी ++ कोड देखा है जहां परिवर्तनीय नामकरण सम्मेलन प्रोग्रामर से वेरिएबल के पाठ से पहले अंडरस्कोर का उपयोग करके परिवर्तनीय नाम लिखने के लिए कहता है। e.gr.क्यों सी # और सी ++ _ <variableName> कोडिंग सम्मेलन का उपयोग करते हैं?
int? _countMoney;
उस सम्मेलन का समर्थन करने वाले तर्क क्या हैं?
सी # में आमतौर पर _ निजी फ़ील्ड के साथ उपसर्ग करता है लेकिन स्थानीय चर कभी नहीं। इसके पीछे तर्क यह है कि जब मुझे एक निजी चर की आवश्यकता होती है तो मैं _ टाइप करता हूं और इंटेलिसेंस सूची फ़िल्टर करता है और यह ढूंढना आसान होता है। इस तरह से मैं स्थानीय चर से निजी के बीच अंतर करने में भी सक्षम हूं और मुझे कक्षा क्षेत्रों के लिए this.variablename टाइप करने की आवश्यकता नहीं है, लेकिन बस _variablename।
निजी सदस्य चर की पहचान करने का यह एक आसान तरीका है।
अन्य सभी सम्मेलनों की तरह यह कोड को समझने में आसान बनाने के बारे में है।
मैंने इसे निजी क्षेत्रों के लिए एक सम्मेलन के रूप में देखा है - उस स्थिति में, यह देखना बहुत आसान है कि एक निजी क्षेत्र का उपयोग किया जा रहा है।
आप उसी प्रश्न को hungarian notation से पूछ सकते हैं।
जोएल ने हंगेरी नोटेशन की एक दिलचस्प रक्षा लिखी: http://www.joelonsoftware.com/articles/Wrong.html –
कुंजी ** ऐप्स हंगरी ** नोटेशन का उपयोग कर रही है, नहीं ** सिस्टम हंगरी **! – CaffGeek
जबकि मैं व्यक्तिगत रूप से हंगेरियन नोटेशन का प्रशंसक नहीं हूं, अगर इसका उपयोग चर के मूल्य का वर्णन करने के लिए किया जा रहा है, तो मुझे लगता है कि यह कहीं अधिक स्वीकार्य है।ऐसा तब होता है जब लोग इसे किसी चर के प्रकार की तरह इंगित करने के लिए उपयोग करते हैं, जो मुझे लगता है कि इसका दुरुपयोग किया गया है। जोएल के लेख में, वह "असुरक्षित तार" को दर्शाने के लिए "हमें" उपसर्ग का उपयोग करने के बारे में बात करता है। मैं तर्क दूंगा कि एक आधुनिक भाषा में, जैसे सी #, यदि आप इस तरह के उपसर्ग का उपयोग करना चाहते हैं, तो यदि आप उपसर्ग "हमें" को "असुरक्षित" में विस्तारित करते हैं तो कोड अधिक स्पष्ट होगा। –
कभी-कभी लोग स्थानीय चर से अलग करने में सहायता के लिए सदस्य चर में ऐसा करते हैं। यदि आप सीधे अंडरस्कोर चर का उपयोग कर रहे हैं, तो हो सकता है कि आपको इसके बजाय एक्सेस के लिए गेटर/सेटर का उपयोग करना चाहिए।
इस उत्तर के साथ क्या गलत है? मुझे बिंदु पूरी तरह से मान्य लगता है। – Lazer
अन्य लोगों की तरह कहा गया है कि नामकरण सम्मेलन स्थानीय लोगों से सदस्य चर को अलग करने में मदद करता है।
रोकता संघर्ष नामकरण: यह दो प्रमुख लाभ देता है। मैं की तरह एक निर्माता लिख सकते हैं:
SomeObject(int foo, int bar)
{
_foo = foo;
_bar = bar;
}
इस तरह, मैं तर्क new_foo या ऐसा ही कुछ नाम हैं नहीं है।
कम से कम सी ++ में, आप इस तरह के एक निर्माता को लिख सकते हैं: 'SomeObject (int foo, int bar): foo (foo), बार (बार) {} ', और" सही "चीज़ होती है। –
@ ओली: जिसका अर्थ यह नहीं है कि आपको वास्तव में ऐसा करना चाहिए ... – sbi
सच। यह कुछ है जो मैंने अपने सी # दिनों में सीखा (जहां सदस्य प्रारंभकर्ता सूचियों की अनुमति नहीं है, आईआईआरसी)। –
आपको C++ में उपसर्ग के रूप में _ का उपयोग नहीं करना चाहिए। _ से शुरू होने वाले नाम कंपाइलर के लिए आरक्षित हैं।
सबसे आम उपसर्ग _ के लिए सी # का उपयोग करने के अपने बहुत ही आम C++ M_ है ('सदस्य के रूप में)
।
मेरी साइट है जहाँ हम ग के बराबर राशि कर ++ और सी # हम हमेशा M_ का उपयोग एक समान होना चाहिए सदस्य नामकरण के लिए
नहीं, _ अपरकेस से शुरू होने वाले C++ नामों में आरक्षित हैं। _lowercase ठीक है। – Detmar
@ डेटमार: वास्तव में [यह उससे अधिक जटिल है] (http://stackoverflow.com/questions/3650623/trailing-underscores-for-member-variables-in-c/3651336#3651336), लेकिन आप दोनों के पास अभी भी एक है बिंदु। मानक से – sbi
"अंडरस्कोर से शुरू होने वाला प्रत्येक नाम वैश्विक नामस्थान में नाम के रूप में उपयोग के लिए कार्यान्वयन के लिए आरक्षित है"। सिद्धांत में आप इससे दूर हो सकते हैं, लेकिन किनारे को स्केट क्यों करें? – pm100
माइक्रोसॉफ्ट दिशानिर्देश पर निर्दिष्ट करता है कि आप क्षेत्रों के लिए उपसर्गों का प्रयोग नहीं करते।
फ़ील्ड नामों के लिए उपसर्ग का उपयोग न करें। उदाहरण के लिए, स्थैतिक बनाम गैर स्थैतिक फ़ील्ड को अलग करने के लिए g_ या s_ का उपयोग न करें।
आप नाम here नाम के लिए माइक्रोसॉफ्ट के दिशानिर्देश पढ़ सकते हैं। यह निश्चित रूप से सी # पर लागू होता है।
यह अभी भी एक बहुत ही सामान्य प्रथा है जो समझ में आता है ... –
मैं व्यक्तिगत रूप से उपसर्ग का उपयोग करने के अभ्यास को नापसंद करता हूं। आपके आईडीई को यह स्पष्ट करना चाहिए कि स्थानीय क्या है और सदस्य क्या है। यह निश्चित रूप से व्यक्तिगत स्वाद (या आपके प्रोजेक्ट कोडिंग मानकों) तक है, लेकिन यह उत्तर मेरा +1 प्राप्त करता है। – rmeador
यह उन कुछ दिशानिर्देशों में से एक है जिनसे मैं असहमत हूं। मैं उदाहरण और स्थिर फ़ील्ड के बीच अंतर करने के लिए 'm_' और' s_' का उपयोग करता हूं। यह मेरे लिए महत्वपूर्ण है क्योंकि आपको यह मानना चाहिए कि स्थिर क्षेत्रों को कई धागे से एक्सेस किया जा सकता है और इस तरह आपको थ्रेडिंग मुद्दे के खिलाफ सुरक्षा करने के लिए सावधानी बरतनी चाहिए। इस तरह से उपसर्गों का उपयोग करना किसी भी समस्या के धब्बे होने पर एक नज़र में देखना आसान बनाता है। इस सम्मेलन का प्रस्ताव जेफ़री रिक्टर ने किया था, जो इस दिशानिर्देश को विकसित करने में एक आवाज थी। वह इस विशेष बिंदु पर खो गया होगा :) –
जब मुझे जावा काम करना पड़ा, तो जावा ग्रहों में जावा देव द्वारा मैंने जो कुछ देखा, वह वहां वर्र्स अंडरस्कोर नहीं करेगा। कारण है कि? सदस्यों के निशान आईडीई में कोडित कोड थे ... बोलने के लिए ऐसा करने की कोई आवश्यकता नहीं थी। आदत से यह स्वाभाविक रूप से आया क्योंकि मुझे कुछ दृश्य क्यू के माध्यम से वीएस आईडीई में एक सदस्य var को ढूंढना आसान लगता था ... और अंडरस्कोर यह काफी लोकप्रिय था। दुर्लभ घटना में आपको अपने कच्चे रूप में कोड को देखना होगा ... पाठ ... उन प्रकार की चीजें जबरदस्त मदद करती हैं।
मुझे सच में यकीन नहीं है कि इस सम्मेलन के पीछे तर्क क्या है। व्यक्तिगत रूप से, मुझे किसी चर के दायरे को दर्शाने के लिए किसी भी प्रकार के परिवर्तनीय नाम उपसर्ग के उपयोग की परवाह नहीं है, न ही मैं विशेष रूप से किसी भी नामकरण में अंडरस्कोर के उपयोग की परवाह करता हूं। "इस" कीवर्ड का उपयोग करने और निजी उदाहरण/सदस्य चर के लिए निचले ऊंट-केज्ड नामों के सम्मेलन को अपनाने के बारे में इतना बुरा क्या है?
public void IncrementFoo()
{
this.foo += 1;
}
यह टाइप करने के लिए केवल 5 अतिरिक्त वर्ण हैं, लेकिन यह बहुत स्पष्ट है। यदि आपने अपने निजी आवृत्ति चर के लिए निचले ऊंट-आधारित सम्मेलन को अपनाया है, तो यह आपको तुरंत बताता है कि आप एक निजी उदाहरण/सदस्य चर का उपयोग कर रहे हैं, और आपको इसे इंगित करने के लिए किसी भी प्रकार के उपसर्ग का उपयोग करने की आवश्यकता नहीं है ।
_ उपसर्ग VB.NET में बहुत आवश्यक है क्योंकि यह केस-संवेदी नहीं है। हम सी # और वीबी.नेट दोनों में कोड करते हैं, और हर किसी की स्वच्छता के लिए दोनों भाषाओं में समान नामकरण सम्मेलन होना महत्वपूर्ण है।
मेरे लिए भी +1, मुख्य विचार चर के फ़िल्टरिंग है। – Lazer
मैं सदस्य चर को अलग करने के लिए इंटेलिजेंस से पहले यह कर रहा था। यह सी ++ दिनों और एमएस से सदस्य चर के लिए एम_ का उपयोग कर रहा है –
यदि आप यह निर्धारित नहीं कर सकते कि कोई वैरिएबल स्थानीय है या नहीं, तो किसी विधि को देखने के कुछ सेकंड के भीतर नहीं, तो यह तर्क नहीं दिया जा सकता है कि आपकी विधि हो सकती है बहुत जटिल हो? इंटेलिसेंस फ़िल्टरिंग के लिए, आईडीई की विशिष्ट सुविधा के अनुरूप कोड लिखना वास्तव में एक अच्छा विचार है? –