नेमिंग कन्वेंशन (प्रोग्रामिंग)

From Vigyanwiki
Revision as of 00:06, 15 August 2023 by alpha>Indicwiki (Created page with "{{Short description|Set of rules for naming entities in source code and documentation}} {{Use dmy dates|date=October 2020}} कंप्यूटर प्रोग्रा...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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

  • स्रोत कोड को पढ़ने और समझने के लिए आवश्यक प्रयास को कम करने के लिए;[1]
  • सिंटैक्स और नामकरण मानकों से अधिक महत्वपूर्ण मुद्दों पर ध्यान केंद्रित करने के लिए कोड समीक्षाओं को सक्षम करना।
  • कोड गुणवत्ता समीक्षा टूल को अपनी रिपोर्टिंग को मुख्य रूप से सिंटैक्स और शैली प्राथमिकताओं के अलावा अन्य महत्वपूर्ण मुद्दों पर केंद्रित करने में सक्षम बनाना।

नामकरण परंपराओं का चुनाव एक अत्यंत विवादास्पद मुद्दा हो सकता है, जिसमें प्रत्येक पक्षकार अपने को सर्वोत्तम और दूसरों को निम्नतर मानते हैं। बोलचाल की भाषा में इसे हठधर्मिता का मामला कहा जाता है।[2] कई कंपनियों ने अपने स्वयं के सम्मेलनों का सेट भी स्थापित किया है।

संभावित लाभ

नामकरण परंपरा के लाभों में निम्नलिखित शामिल हो सकते हैं:

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

चुनौतियाँ

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

पठनीयता

अच्छी तरह से चुने गए पहचानकर्ता डेवलपर्स और विश्लेषकों के लिए यह समझना काफी आसान बनाते हैं कि सिस्टम क्या कर रहा है और नई जरूरतों के लिए आवेदन करने के लिए स्रोत कोड को कैसे ठीक या विस्तारित किया जाए।

उदाहरण के लिए, यद्यपि 

 a = b * c;

क्या सिंटैक्स (प्रोग्रामिंग भाषाएँ) सही है, इसका उद्देश्य स्पष्ट नहीं है। इसकी तुलना इससे करें: 

 weekly_pay = hours_worked * hourly_pay_rate;

जो स्रोत कोड के इरादे और अर्थ को दर्शाता है, कम से कम उन लोगों के लिए जो कथन के संदर्भ से परिचित हैं।

प्रयोगों से पता चलता है कि पहचानकर्ता शैली स्मरण और सटीकता को प्रभावित करती है और शैली से परिचित होने से स्मरण की गति तेज हो जाती है।[3]


सामान्य तत्व

नामकरण परंपरा के सटीक नियम उस संदर्भ पर निर्भर करते हैं जिसमें उनका उपयोग किया जाता है। फिर भी, ऐसे कई सामान्य तत्व हैं जो आज आम उपयोग में आने वाली सभी नामकरण परंपराओं को नहीं तो सबसे अधिक प्रभावित करते हैं।

पहचानकर्ताओं की लंबाई

सभी नामकरण परंपराओं के मौलिक तत्व पहचानकर्ता की लंबाई (यानी, पहचानकर्ता में अनुमत व्यक्तिगत वर्णों की सीमित संख्या) से संबंधित नियम हैं। कुछ नियम एक निश्चित संख्यात्मक सीमा निर्धारित करते हैं, जबकि अन्य कम सटीक अनुमान या दिशानिर्देश निर्दिष्ट करते हैं।

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

कुछ विचार:

  • छोटे पहचानकर्ताओं को अधिक समीचीन के रूप में प्राथमिकता दी जा सकती है, क्योंकि उन्हें टाइप करना आसान होता है (हालांकि कई आईडीई और टेक्स्ट-संपादक टेक्स्ट-पूर्णता प्रदान करते हैं, जो इसे कम करता है)
  • अत्यंत संक्षिप्त पहचानकर्ता (जैसे कि 'i' या 'j') को स्वचालित खोज और प्रतिस्थापन टूल का उपयोग करके विशिष्ट रूप से अलग करना बहुत मुश्किल है (हालांकि यह नियमित अभिव्यक्ति-आधारित टूल के लिए कोई समस्या नहीं है)
  • लंबे पहचानकर्ताओं को प्राथमिकता दी जा सकती है क्योंकि छोटे पहचानकर्ता पर्याप्त जानकारी को एन्कोड नहीं कर सकते हैं या बहुत गूढ़ दिखाई देते हैं
  • दृश्य अव्यवस्था के कारण लंबे पहचानकर्ताओं को नापसंद किया जा सकता है

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

प्रोग्रामिंग में संक्षिप्तता का कुछ हद तक कारण यह हो सकता है:

  • प्रारंभिक लिंकर (कंप्यूटिंग) जिसमें मेमोरी को बचाने के लिए वेरिएबल नामों को 6 अक्षरों तक सीमित करना आवश्यक था। बाद की प्रगति ने मानवीय समझ के लिए लंबे परिवर्तनशील नामों का उपयोग करने की अनुमति दी, लेकिन जहां केवल पहले कुछ अक्षर ही महत्वपूर्ण थे। बुनियादी के कुछ संस्करणों जैसे टीआरएस-80 लेवल 2 बेसिक में, लंबे नामों की अनुमति थी, लेकिन केवल पहले दो अक्षर ही महत्वपूर्ण थे। इस सुविधा ने गलत व्यवहार की अनुमति दी जिसे डीबग करना मुश्किल हो सकता है, उदाहरण के लिए जब VALUE और VAT जैसे नामों का उपयोग किया गया था और अलग होने का इरादा था।
  • प्रारंभिक स्रोत कोड संपादकों में स्वत: पूर्णता का अभाव है
  • प्रारंभिक कम-रिज़ॉल्यूशन मॉनिटर सीमित लाइन लंबाई के साथ (उदाहरण के लिए केवल 80 अक्षर)
  • कंप्यूटर विज्ञान का अधिकांश भाग गणित से उत्पन्न हुआ है, जहां चर नाम परंपरागत रूप से केवल एक अक्षर होते हैं

अक्षर केस और अंक

कुछ नामकरण परंपराएं यह सीमित करती हैं कि अक्षर अपरकेस या लोअरकेस में दिखाई दे सकते हैं या नहीं। अन्य परंपराएं अक्षर मामले को प्रतिबंधित नहीं करतीं, बल्कि एक अच्छी तरह से परिभाषित व्याख्या आधारित करती हैं पत्र मामले पर. कुछ नामकरण परंपराएँ निर्दिष्ट करती हैं कि वर्णमाला, संख्यात्मक या अल्फ़ान्यूमेरिक वर्णों का उपयोग किया जा सकता है, और यदि हां, तो किस क्रम में।

एकाधिक-शब्द पहचानकर्ता

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

चूंकि अधिकांश प्रोग्रामिंग भाषाएं पहचानकर्ताओं में व्हाइटस्पेस (कंप्यूटर विज्ञान) की अनुमति नहीं देती हैं, इसलिए प्रत्येक शब्द को परिसीमित करने की एक विधि की आवश्यकता होती है (बाद के पाठकों के लिए यह व्याख्या करना आसान हो जाता है कि कौन से अक्षर किस शब्द से संबंधित हैं)। ऐतिहासिक रूप से कुछ प्रारंभिक भाषाओं, विशेष रूप से फोरट्रान (1955) और एएलजीओएल (1958) ने, संदर्भ के अनुसार पहचानकर्ताओं के अंत का निर्धारण करते हुए, पहचानकर्ताओं के भीतर रिक्त स्थान की अनुमति दी। टोकनाइजेशन (शब्दावली विश्लेषण) की कठिनाई के कारण बाद की भाषाओं में इसे छोड़ दिया गया। केवल शब्दों को जोड़कर नाम लिखना संभव है, और इसका उपयोग कभी-कभी किया जाता है, जैसे कि mypackage जावा पैकेज नामों के लिए,[4] हालाँकि लंबे समय तक सुपाठ्यता प्रभावित होती है, इसलिए आमतौर पर किसी न किसी रूप में पृथक्करण का उपयोग किया जाता है।

सीमांकक-पृथक शब्द

एक दृष्टिकोण अक्षरांकीय वर्ण के साथ अलग-अलग शब्दों को परिसीमित करना है। इस उद्देश्य के लिए आमतौर पर उपयोग किए जाने वाले दो अक्षर हैफ़ेन (-) और बल देना (_) हैं; उदाहरण के लिए, दो शब्दों वाला नामtwo wordsके रूप में दर्शाया जाएगाtwo-wordsयाtwo_words.

हाइफ़न का उपयोग COBOL (1959), फोर्थ (प्रोग्रामिंग भाषा) (1970), और लिस्प (प्रोग्रामिंग भाषा) (1958) लिखने वाले लगभग सभी प्रोग्रामर द्वारा किया जाता है; यह यूनिक्स में कमांड और पैकेज के लिए भी आम है, और इसका उपयोग व्यापक शैली पत्रक में किया जाता है।[5] इस कन्वेंशन का कोई मानक नाम नहीं है, हालाँकि इसे लिस्प-केस या COBOL-CASE (पास्कल केस की तुलना करें), कबाब-केस, ब्रोचेट-केस या अन्य वेरिएंट के रूप में संदर्भित किया जा सकता है।[6][7][8][9] इनमें से, कबाब-केस, कम से कम 2012 का है,[10] तब से कुछ मुद्रा हासिल की है।[11][12] इसके विपरीत, फोरट्रान/एएलजीओएल परंपरा की भाषाएं, विशेष रूप से सी (प्रोग्रामिंग भाषा) और पास्कल (प्रोग्रामिंग भाषा) परिवारों की भाषाएं, घटाव इन्फिक्स संकेतन ऑपरेटर के लिए हाइफ़न का उपयोग करती थीं, और इसके चारों ओर रिक्त स्थान की आवश्यकता नहीं चाहती थीं (जैसा कि मुफ़्त है) -फ़ॉर्म भाषाएँ), पहचानकर्ताओं में इसके उपयोग को रोकना।

एक विकल्प अंडरस्कोर का उपयोग करना है; यह सी परिवार (पायथन सहित) में आम है, छोटे अक्षरों के साथ, उदाहरण के सी प्रोग्रामिंग भाषा (1978) में पाया जाता है, और इसे साँप का मामला या स्नेल केस के रूप में जाना जाता है। अपरकेस के साथ अंडरस्कोर, जैसे कि UPPER_CASE में, आमतौर पर सी प्रीप्रोसेसर मैक्रोज़ के लिए उपयोग किया जाता है, इसलिए इसे MACRO_CASE के रूप में जाना जाता है, और यूनिक्स में पर्यावरण चर के लिए, जैसे बैश (यूनिक्स शेल) में BASH_VERSION के लिए उपयोग किया जाता है। कभी-कभी इसे मज़ाकिया तौर पर SCREAMING_SNAKE_CASE (वैकल्पिक रूप से SCREAMING_SNAIL_CASE) कहा जाता है।

अक्षर केस-पृथक शब्द

See also: Letter case § Special case styles

एक अन्य दृष्टिकोण मध्यस्थ पूंजीकरण का उपयोग करके शब्द सीमाओं को इंगित करना है, जिसे टेढ़े - मेढ़े लिखावट वाले बड़े संयुक्त शब्द, पास्कलकेस और कई अन्य नाम कहा जाता है, इस प्रकार क्रमशः प्रतिपादन किया जाता हैtwo wordsजैसाtwoWordsयाTwoWords. यह कन्वेंशन आमतौर पर पास्कल (प्रोग्रामिंग भाषा), जावा (प्रोग्रामिंग भाषा), सी शार्प (प्रोग्रामिंग भाषा)|सी#, और मूल दृश्य में उपयोग किया जाता है। पहचानकर्ताओं में आरंभिक शब्दों का उपचार (उदाहरण के लिए XML और HTTP में)। XMLHttpRequest) भिन्न होता है। कुछ लोग निर्देश देते हैं कि उन्हें छोटा किया जाए (उदा. XmlHttpRequest) टाइपिंग, पठनीयता और पाठ विभाजन को आसान बनाने के लिए, जबकि अन्य उन्हें बड़े अक्षरों में छोड़ देते हैं (उदाहरण के लिए) XMLHTTPRequest) सटीकता के लिए।

बहु-शब्द पहचानकर्ता प्रारूपों के उदाहरण

Multiple-word identifier formats
Formatting Name(s)
twowords flatcase[13][14]
TWOWORDS UPPERCASE[13]
twoWords (lower) camelCase, dromedaryCase
TwoWords PascalCase, UpperCamelCase, StudlyCase[15]
two_words snake_case, snail_case, pothole_case
TWO_WORDS ALL_CAPS, SCREAMING_SNAKE_CASE,[16] MACRO_CASE, CONSTANT_CASE
two_Words camel_Snake_Case
Two_Words Pascal_Snake_Case, Title_Case
two-words kebab-case, dash-case, lisp-case, spinal-case
TWO-WORDS TRAIN-CASE, COBOL-CASE, SCREAMING-KEBAB-CASE
Two-Words Train-Case,[13] HTTP-Header-Case[17]


मेटाडेटा और हाइब्रिड कन्वेंशन

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

हंगेरियन संकेतन

शायद सबसे प्रसिद्ध हंगेरियन नोटेशन है, जो अपने नाम में एक चर के उद्देश्य (एप्स हंगेरियन) या डेटा प्रकार (सिस्टम हंगेरियन) को एन्कोड करता है।[18] उदाहरण के लिए, वेरिएबल szName के लिए उपसर्ग sz इंगित करता है कि वेरिएबल एक शून्य-समाप्त स्ट्रिंग है।

स्थिति संकेतन

बहुत कम (आठ अक्षर और उससे कम) के लिए उपयोग की जाने वाली शैली हो सकती है: LCCIIL01, जहां LC अनुप्रयोग (लेटर ऑफ क्रेडिट) होगा, C COBOL के लिए, IIL विशेष प्रक्रिया उपसमुच्चय के लिए, और 01 एक अनुक्रम संख्या होगी।

इस प्रकार का सम्मेलन अभी भी कार्य नियंत्रण भाषा पर निर्भर मेनफ्रेम में सक्रिय उपयोग में है और इसे 8.3 (पीरियड सेपरेटर के साथ अधिकतम आठ अक्षर और उसके बाद तीन अक्षर फ़ाइल प्रकार) एमएस-डॉस शैली में भी देखा जाता है।

समग्र शब्द योजना (भाषा की)

IBM की OF भाषा को IMS (सूचना प्रबंधन प्रणाली) मैनुअल में प्रलेखित किया गया था।

इसमें प्राइम-मोडिफायर-क्लास शब्द योजना का विवरण दिया गया, जिसमें ग्राहक खाता संख्या को इंगित करने के लिए CUST-ACT-NO जैसे नाम शामिल थे।

PRIME शब्द किसी सिस्टम में रुचि रखने वाली प्रमुख संस्थाओं को इंगित करने के लिए थे।

अतिरिक्त परिशोधन, योग्यता और पठनीयता के लिए संशोधक शब्दों का प्रयोग किया गया।

क्लास शब्द आदर्श रूप से किसी विशेष एप्लिकेशन के लिए प्रासंगिक डेटा प्रकारों की एक बहुत छोटी सूची होगी। सामान्य वर्ग के शब्द हो सकते हैं: NO (संख्या), ID (पहचानकर्ता), TXT (पाठ), AMT (राशि), QTY (मात्रा), FL (ध्वज), CD (कोड), W (कार्य) इत्यादि। व्यवहार में, उपलब्ध क्लास शब्द दो दर्जन से कम शब्दों की एक सूची होगी।

क्लास शब्द, आमतौर पर दाईं ओर (प्रत्यय) स्थित होते हैं, हंगेरियन नोटेशन उपसर्गों के समान ही उद्देश्य पूरा करते हैं।

क्लास शब्दों का उद्देश्य, स्थिरता के अलावा, प्रोग्रामर को किसी विशेष डेटा फ़ील्ड के डेटा प्रकार को निर्दिष्ट करना था। बूलियन (केवल दो मान) फ़ील्ड की स्वीकृति से पहले, FL (ध्वज) केवल दो संभावित मानों वाले फ़ील्ड को इंगित करेगा।

भाषा-विशिष्ट परंपराएँ

एकमा स्क्रिप्ट

एडोब के कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास ActionScript के लिए नामकरण मानकों का सुझाव देते हैं जो ज्यादातर ईसीएमएस्क्रिप्ट के अनुरूप होते हैं।[citation needed] पहचानकर्ताओं की शैली जावा (प्रोग्रामिंग भाषा) के समान है।

अदा

एडा (प्रोग्रामिंग भाषा) में, पहचानकर्ताओं की एकमात्र अनुशंसित शैली है Mixed_Case_With_Underscores.[19]


एपीएल

एपीएल (प्रोग्रामिंग भाषा) बोलियों में, डेल्टा (Δ) का उपयोग शब्दों के बीच किया जाता है, जैसे PERFΔSQUARE (पुराने एपीएल संस्करणों में पारंपरिक रूप से कोई लोअरकेस मौजूद नहीं था)। यदि नाम में अंडरस्कोर वाले अक्षरों का उपयोग किया गया है, तो इसके स्थान पर डेल्टा अंडरबार (⍙) का उपयोग किया जाएगा।

सी और सी++

C (प्रोग्रामिंग भाषा) और C++ में, कीवर्ड (कंप्यूटर प्रोग्रामिंग) और मानक लाइब्रेरी पहचानकर्ता अधिकतर लोअरकेस होते हैं। सी मानक लाइब्रेरी में, संक्षिप्त नाम सबसे आम हैं (उदाहरण के लिए) isalnum किसी फ़ंक्शन के परीक्षण के लिए कि क्या कोई वर्ण अल्फ़ान्यूमेरिक है), जबकि C++ मानक लाइब्रेरी अक्सर शब्द विभाजक के रूप में अंडरस्कोर का उपयोग करती है (उदा. out_of_range). सी प्रीप्रोसेसर#मैक्रो परिभाषा और विस्तार का प्रतिनिधित्व करने वाले पहचानकर्ता, परंपरा के अनुसार, केवल अपरकेस अक्षरों और अंडरस्कोर का उपयोग करके लिखे गए हैं (यह कई प्रोग्रामिंग भाषाओं में स्थिरांक के लिए सभी-अपर-केस पहचानकर्ताओं का उपयोग करने की परंपरा से संबंधित है)। डबल अंडरस्कोर वाले या अंडरस्कोर और बड़े अक्षर से शुरू होने वाले नाम कार्यान्वयन (संकलक , मानक लाइब्रेरी) के लिए आरक्षित हैं और उनका उपयोग नहीं किया जाना चाहिए (उदाहरण के लिए) __reserved या _Reserved).[20][21] यह सतही तौर पर स्ट्रॉपिंग (वाक्यविन्यास) के समान है, लेकिन शब्दार्थ अलग-अलग हैं: अंडरस्कोर वर्णों को उद्धृत करने के बजाय पहचानकर्ता के मूल्य का हिस्सा हैं (जैसा कि स्ट्रॉपिंग है): का मूल्य __foo है __foo (जो आरक्षित है), नहीं foo (लेकिन एक अलग नामस्थान में)।

सी#

सी शार्प (प्रोग्रामिंग भाषा)|सी# नामकरण परंपराएं आम तौर पर सभी .NET भाषाओं के लिए माइक्रोसॉफ्ट द्वारा प्रकाशित दिशानिर्देशों का पालन करती हैं[22] (नीचे .NET अनुभाग देखें), लेकिन C# कंपाइलर द्वारा कोई परंपरा लागू नहीं की जाती है।

Microsoft दिशानिर्देश केवल इसके विशेष उपयोग की अनुशंसा करते हैं PascalCase और camelCase, बाद वाले का उपयोग केवल विधि पैरामीटर नामों और विधि-स्थानीय चर नामों (विधि-स्थानीय सहित) के लिए किया जाता है const मान)। पास्कलकेस में एक विशेष अपवाद दो-अक्षर वाले संक्षिप्ताक्षरों के लिए बनाया गया है जो एक पहचानकर्ता शुरू करते हैं; इन मामलों में, दोनों अक्षर बड़े अक्षरों में लिखे गए हैं (उदाहरण के लिए, IOStream); लंबे संक्षिप्त शब्दों के मामले में ऐसा नहीं है (उदाहरण के लिए, XmlStream). दिशानिर्देश आगे अनुशंसा करते हैं कि जो नाम दिया गया है interface होना PascalCase बड़े अक्षर से पहले I, के रूप में IEnumerable.

फ़ील्ड के नामकरण के लिए Microsoft दिशानिर्देश विशिष्ट हैं static, public, और protected खेत; फ़ील्ड जो नहीं हैं static और उसके पास अन्य पहुंच स्तर हैं (जैसे internal और private) स्पष्ट रूप से दिशानिर्देशों में शामिल नहीं हैं।[23] उपयोग करना सबसे आम अभ्यास है PascalCase सभी फ़ील्ड के नामों के लिए, उन्हें छोड़कर जो मौजूद हैं private (और ना ही const और न static), जो उपयोग किए जाने वाले नाम दिए गए हैं camelCase एकल अंडरस्कोर से पहले; उदाहरण के लिए, _totalCount.

किसी भी पहचानकर्ता नाम के पहले वाणिज्यिक-एट प्रतीक लगाया जा सकता है (@), अर्थ में कोई बदलाव किए बिना। यानी दोनों factor और @factor एक ही वस्तु का संदर्भ लें. परंपरा के अनुसार, इस उपसर्ग का उपयोग केवल उन मामलों में किया जाता है जब पहचानकर्ता अन्यथा एक आरक्षित कीवर्ड होगा (जैसे for और while), जिसका उपयोग उपसर्ग, या प्रासंगिक कीवर्ड (जैसे कि) के बिना पहचानकर्ता के रूप में नहीं किया जा सकता है from और where), किन मामलों में उपसर्ग की सख्ती से आवश्यकता नहीं है (कम से कम इसकी घोषणा पर नहीं; उदाहरण के लिए, हालांकि घोषणा dynamic dynamic; वैध है, इसे आमतौर पर इस रूप में देखा जाएगा dynamic @dynamic; पाठक को तुरंत इंगित करने के लिए कि बाद वाला एक परिवर्तनीय नाम है)।

डार्ट/फड़फड़ाना

फ़्लटर_(सॉफ़्टवेयर) में प्रयुक्त डार्ट_(प्रोग्रामिंग_भाषा) भाषा में, कन्वेंशन जावा के समान हैं, सिवाय इसके कि स्थिरांक लोअरकैमलकेस में लिखे गए हैं। डार्ट वाक्यात्मक नियम लागू करता है कि गैर-स्थानीय पहचानकर्ता अंडरस्कोर से शुरू होते हैं (_) को निजी माना जाता है (चूंकि भाषा में सार्वजनिक या निजी पहुंच के लिए स्पष्ट कीवर्ड नहीं हैं)। इसके अतिरिक्त, स्रोत फ़ाइल नाम जावा के प्रति स्रोत फ़ाइल के एक सार्वजनिक वर्ग का पालन नहीं करते हैं, नाम नियम से मेल खाना चाहिए, इसके बजाय फ़ाइल नाम के लिए साँप_केस का उपयोग करें।[24]


जाओ

गो (प्रोग्रामिंग भाषा) में, कन्वेंशन का उपयोग करना है MixedCaps या mixedCaps बहुशब्दीय नाम लिखने के लिए अंडरस्कोर के बजाय। संरचनाओं या कार्यों का संदर्भ देते समय, पहला अक्षर बाहरी पैकेजों के लिए दृश्यता निर्दिष्ट करता है। पहला अक्षर अपरकेस बनाने से कोड का वह टुकड़ा निर्यात हो जाता है, जबकि लोअरकेस इसे केवल मौजूदा दायरे में ही प्रयोग करने योग्य बनाता है।[25]


जावा

जावा (प्रोग्रामिंग भाषा) में, पहचानकर्ताओं के लिए नामकरण परंपराएं विभिन्न जावा समुदायों जैसे सन माइक्रोसिस्टम्स, द्वारा स्थापित और सुझाई गई हैं।[26] नेटस्केप,[27] एम्बीसॉफ्ट,[28] आदि। सन माइक्रोसिस्टम्स द्वारा निर्धारित नामकरण परंपराओं का एक नमूना नीचे सूचीबद्ध है, जहां CamelCase में एक नाम बिना रिक्त स्थान के जुड़े हुए कई शब्दों से बना है, प्रत्येक शब्द का - पहले शब्द को छोड़कर - बड़े अक्षरों में प्रारंभिक अक्षर - उदाहरण के लिए CamelCase।

Identifier type Rules for naming Examples
Classes Class names should be nouns in UpperCamelCase, with the first letter of every word capitalised. Use whole words – avoid acronyms and abbreviations (unless the abbreviation is much more widely used than the long form, such as URL or HTML).
  • class Raster {}
  • class ImageSprite {}
Methods Methods should be verbs in lowerCamelCase or a multi-word name that begins with a verb in lowercase; that is, with the first letter lowercase and the first letters of subsequent words in uppercase.
  • run();
  • runFast();
  • getBackground();
Variables Local variables, instance variables, and class variables are also written in lowerCamelCase. Variable names should not start with underscore (_) or dollar sign ($) characters, even though both are allowed. This is in contrast to other coding conventions that state that underscores should be used to prefix all instance variables.

Variable names should be short yet meaningful. The choice of a variable name should be mnemonic — that is, designed to indicate to the casual observer the intent of its use. One-character variable names should be avoided except for temporary "throwaway" variables. Common names for temporary variables are i, j, k, m, and n for integers; c, d, and e for characters.

  • int i;
  • char c;
  • float myWidth;
Constants Constants should be written in uppercase characters separated by underscores. Constant names may also contain digits if appropriate, but not as the first character.
  • static final int MAX_PARTICIPANTS = 10;

जावा कंपाइलर इन नियमों को लागू नहीं करते हैं, लेकिन उनका पालन करने में विफल रहने से भ्रम और गलत कोड हो सकता है। उदाहरण के लिए, widget.expand() और Widget.expand() महत्वपूर्ण रूप से भिन्न व्यवहार दर्शाते हैं: widget.expand() विधि के आह्वान का तात्पर्य है expand() नामक एक उदाहरण में widget, जबकि Widget.expand() स्थैतिक विधि के आह्वान का तात्पर्य है expand() कक्षा में Widget.

व्यापक रूप से उपयोग की जाने वाली जावा कोडिंग शैली यही निर्देशित करती है UpperCamelCase कक्षा (कंप्यूटर विज्ञान) और के लिए उपयोग किया जाए lowerCamelCase उदाहरण के लिए (कंप्यूटर विज्ञान) और विधि (कंप्यूटर विज्ञान) का उपयोग किया जाना चाहिए।[26]इस उपयोग को पहचानते हुए, कुछ एकीकृत विकास वातावरण, जैसे कि ग्रहण (आईडीई)आईडीई), कैमलकेस पर आधारित शॉर्टकट लागू करते हैं। उदाहरण के लिए, एक्लिप्स की सामग्री सहायता सुविधा में, कैमलकेस शब्द के केवल बड़े अक्षरों को टाइप करने से कोई भी मिलान वर्ग या विधि का नाम सुझाया जाएगा (उदाहरण के लिए, एनपीई टाइप करना और सामग्री सहायता को सक्रिय करना सुझाव दे सकता है) NullPointerException).

तीन या अधिक अक्षरों के प्रथमाक्षर अपरकेस के बजाय CamelCase हैं (जैसे, parseDbmXmlFromIPAddress के बजाय parseDBMXMLFromIPAddress). कोई व्यक्ति दो या अधिक अक्षरों पर भी सीमा निर्धारित कर सकता है (उदा. parseDbmXmlFromIpAddress).

जावास्क्रिप्ट

अंतर्निहित जावास्क्रिप्ट लाइब्रेरीज़ जावा के समान नामकरण परंपराओं का उपयोग करती हैं। डेटा प्रकार और कंस्ट्रक्टर फ़ंक्शन अपर कैमल केस का उपयोग करते हैं (RegExp, TypeError, XMLHttpRequest, DOMObject) और विधियाँ लोअर कैमल केस का उपयोग करती हैं (getElementById, getElementsByTagNameNS, createCDATASection). सुसंगत रहने के लिए अधिकांश जावास्क्रिप्ट डेवलपर इन सम्मेलनों का पालन करते हैं।[29] यह भी देखें: डगलस क्रॉकफोर्ड के सम्मेलन

लिस्प

अधिकांश लिस्प (प्रोग्रामिंग भाषा) बोलियों में सामान्य अभ्यास पहचानकर्ताओं में शब्दों को अलग करने के लिए डैश का उपयोग करना है, जैसा कि with-open-file और make-hash-table. गतिशील चर नाम परंपरागत रूप से तारांकन के साथ शुरू और समाप्त होते हैं: *map-walls*. स्थिरांकों के नाम धन चिह्न से चिह्नित होते हैं: +map-size+.[30][31]


.NET

Microsoft .NET अनुशंसा करता है UpperCamelCase, जिसे अधिकांश पहचानकर्ताओं के लिए पास्कलकेस के रूप में भी जाना जाता है। (lowerCamelCase पैरामीटर (कंप्यूटर विज्ञान) और चर (प्रोग्रामिंग) ) के लिए अनुशंसित है और यह .NET भाषाओं के लिए एक साझा सम्मेलन है।[32] माइक्रोसॉफ्ट आगे अनुशंसा करता है कि किसी भी प्रकार के उपसर्ग संकेत (जिसे हंगेरियन नोटेशन के रूप में भी जाना जाता है) का उपयोग नहीं किया जाता है।[33] हंगेरियन नोटेशन का उपयोग करने के बजाय नाम को बेस क्लास के नाम से समाप्त करने की अनुशंसा की जाती है; LoginButton के बजाय BtnLogin.[34]


उद्देश्य-सी

उद्देश्य सी की एक सामान्य कोडिंग शैली है जिसकी जड़ें स्मॉलटॉक में हैं।

शीर्ष-स्तरीय इकाइयाँ, जिनमें कक्षाएं, प्रोटोकॉल, श्रेणियाँ, साथ ही सी निर्माण शामिल हैं, जिनका उपयोग वैश्विक चर और फ़ंक्शंस जैसे ऑब्जेक्टिव-सी कार्यक्रमों में किया जाता है, अपरकैमलकेस में नेमस्पेस को दर्शाते हुए एक छोटे ऑल-अपरकेस उपसर्ग के साथ हैं, जैसे NSString, UIAppDelegate, NSApp या CGRectMake. स्थिरांक को वैकल्पिक रूप से छोटे अक्षर k जैसे उपसर्ग के साथ जोड़ा जा सकता है kCFBooleanTrue.

किसी ऑब्जेक्ट के इंस्टेंस वेरिएबल लोअरकैमलकेस का उपयोग करते हैं जो अंडरस्कोर के साथ उपसर्ग होता है, जैसे _delegate और _tableView.

विधि नाम कोलन द्वारा अलग किए गए कई लोअरकैमलकेस भागों का उपयोग करते हैं जो तर्कों को सीमित करते हैं, जैसे: application:didFinishLaunchingWithOptions:, stringWithFormat: और isRunning.

पास्कल, मोडुला-2 और ओबेरॉन

विर्थियन भाषाएँ आमतौर पर पास्कल, मोडुला-2 और ओबेरॉन का उपयोग करते हैं Capitalized या UpperCamelCase प्रोग्राम, मॉड्यूल, स्थिरांक, प्रकार और प्रक्रियाओं के लिए पहचानकर्ता, और lowercase या lowerCamelCase गणित स्थिरांक, चर, औपचारिक पैरामीटर और फ़ंक्शन के लिए पहचानकर्ता।[35] जबकि कुछ बोलियाँ पहचानकर्ताओं में अंडरस्कोर और डॉलर संकेतों का समर्थन करती हैं, स्नेक केस और मैक्रो केस विदेशी एपीआई इंटरफेस के भीतर उपयोग तक ही सीमित हैं।[36]


पर्ल

पर्ल सम्मेलनों के लिए अपनी सी विरासत से कुछ संकेत लेता है। स्थानीय रूप से स्कोप्ड वेरिएबल और सबरूटीन नाम इनफ़िक्स अंडरस्कोर के साथ लोअरकेस में हैं। प्राइवेट माने जाने वाले सबरूटीन्स और वेरिएबल्स के पहले अंडरस्कोर लगा होता है। पैकेज वेरिएबल शीर्षक आवरण वाले हैं। घोषित स्थिरांक सभी अधिकतम सीमाएँ हैं। प्राग्माटा को छोड़कर पैकेज के नाम कैमल केस हैं—उदाहरण के लिए, strict और mro-जो लोअरकेस हैं। [37] [38]


पीएचपी

PHP सिफ़ारिशें PSR-1 (PHP मानक सिफ़ारिश 1) और PSR-12 में शामिल हैं।[39] PSR-1 के अनुसार, क्लास के नाम पास्कलकेस में होने चाहिए, क्लास स्थिरांक MACRO_CASE में होने चाहिए, और फ़ंक्शन और विधि के नाम कैमलकेस में होने चाहिए।[40]


पायथन और रूबी

पायथन (प्रोग्रामिंग भाषा) और रूबी (प्रोग्रामिंग भाषा) दोनों अनुशंसित हैं UpperCamelCase वर्ग के नाम के लिए, CAPITALIZED_WITH_UNDERSCORES स्थिरांक के लिए, और snake_case अन्य नामों के लिए.

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


आर

जबकि आर (प्रोग्रामिंग भाषा) के लिए कोई आधिकारिक स्टाइल गाइड नहीं है, आर-गुरु हैडली विकम की टिडीवर्स स्टाइल गाइड अधिकांश उपयोगकर्ताओं के लिए मानक निर्धारित करती है।[42] यह मार्गदर्शिका फ़ाइल नामों में विशेष वर्णों से बचने और वेरिएबल और फ़ंक्शन नामों के लिए केवल संख्याओं, अक्षरों और अंडरस्कोर का उपयोग करने की अनुशंसा करती है। फिट_मॉडल.आर.

राकू

राकू (प्रोग्रामिंग भाषा) कमोबेश पर्ल जैसी ही परंपराओं का पालन करती है, सिवाय इसके कि यह एक इन्फ़िक्स हाइफ़न की अनुमति देती है - या एक धर्मोपदेश ' (या एकल उद्धरण) एक पहचानकर्ता के भीतर (लेकिन एक पंक्ति में दो नहीं), बशर्ते कि इसके बाद एक वर्णमाला वर्ण हो। राकू प्रोग्रामर अक्सर अपने पहचानकर्ताओं में कबाब केस का उपयोग करते हैं; उदाहरण के लिए, 

fish-food और don't-do-that वैध पहचानकर्ता हैं.

[43]


जंग

रस्ट (प्रोग्रामिंग भाषा) अनुशंसा करता है UpperCamelCase प्रकार के उपनाम और संरचना, विशेषता, एनम और एनम प्रकार के नामों के लिए, SCREAMING_SNAKE_CASE स्थिरांक या स्थैतिक के लिए और snake_case वेरिएबल, फ़ंक्शन और संरचना सदस्य नामों के लिए।[44]


स्विफ्ट

स्विफ्ट (प्रोग्रामिंग भाषा) ने प्रत्येक व्यक्तिगत रिलीज के साथ अपनी नामकरण परंपराओं को बदल दिया है। हालाँकि स्विफ्ट 3.0 के साथ एक प्रमुख अद्यतन ने नामकरण परंपराओं को स्थिर कर दिया lowerCamelCase चर और फ़ंक्शन घोषणाओं में। स्थिरांक को आमतौर पर एनम प्रकार या स्थिर मापदंडों द्वारा परिभाषित किया जाता है जिन्हें इस तरह भी लिखा जाता है। क्लास और अन्य ऑब्जेक्ट प्रकार की घोषणाएँ हैं UpperCamelCase.

स्विफ्ट 3.0 के अनुसार सभी तृतीय पक्ष एपीआई में एपीआई नामकरण और घोषणा सम्मेलनों को मानकीकृत करने के प्रयास में भाषा के लिए स्पष्ट नामकरण दिशानिर्देश बनाए गए हैं। 

[45]


यह भी देखें

संदर्भ

  1. ↑ Derek M. Jones "Operand names influence operator precedence decisions" An experiment investigating the effect of variable names on operator precedence selection
  2. ↑ Raymond, Eric S. (1 October 2004). "धार्मिक मुद्दे". The Jargon File (version 4.4.8 ed.). Retrieved 7 November 2011.
  3. ↑ Binkley, Dave; Davis, Marcia (2009). "To camelcase or under_score" (PDF). 2009 IEEE 17th International Conference on Program Comprehension. pp. 158–167. doi:10.1109/ICPC.2009.5090039. ISBN 978-1-4244-3998-0. S2CID 1450798.
  4. ↑ Naming a Package
  5. ↑ "सीएसएस संदर्भ". Mozilla Developer Network. Retrieved 18 June 2016.
  6. ↑ "StackOverflow – What's the name for snake_case with dashes?".
  7. ↑ "Programmers – If this is camelCase what-is-this?".
  8. ↑ "Camel_SNAKE-kebab". GitHub. September 2019.
  9. ↑ UnderscoreVersusCapitalAndLowerCaseVariableNaming
  10. ↑ jwfearn (5 September 2012). "Revisions to jwfearn's answer to What's the name for dash-separated case?".
  11. ↑ Living Clojure (2015), by Carin Meier, p. 91
  12. ↑ lodash: kebabCase
  13. ↑ 13.0 13.1 13.2 "naming - What are the different kinds of cases?". Stack Overflow. Retrieved 16 August 2020.
  14. ↑ "A brief list of programming naming conventions". deanpugh.com (in British English). 20 March 2018. Retrieved 16 August 2020.
  15. ↑ "PSR-1: Basic Coding Standard - PHP-FIG". www.php-fig.org (in English). Retrieved 4 September 2020.
  16. ↑ "Naming conventions". doc.rust-lang.org. Retrieved 2 May 2023.
  17. ↑ "camel-snake-kebab". camel-snake-kebab (in English). Retrieved 16 August 2020.
  18. ↑ "गलत कोड बनाना गलत दिखना". Joel on Software. 11 May 2005.
  19. ↑ "3.2.1 Names - Chapter 3 - Ada 95 QUALITY AND STYLE Guide".
  20. ↑ "ISO/IEC 9899:1999 Programming languages – C". ISO.
  21. ↑ "ISO/IEC 14882:2011 Information technology – Programming languages – C++". ISO.
  22. ↑ "नामकरण दिशानिर्देश". Microsoft. 15 September 2021.
  23. ↑ "प्रकार सदस्यों के नाम". Microsoft. 15 September 2021.
  24. ↑ "Effective Dart - the Dart Style Guide".
  25. ↑ "Effective Go - the Go Programming Language".
  26. ↑ 26.0 26.1 "Code Conventions for the Java Programming Language", Section 9: "Naming Conventions"
  27. ↑ "NETSCAPE'S SOFTWARE CODING STANDARDS GUIDE FOR JAVA",Collab Software Coding Standards Guide for Java Archived 3 March 2009 at the Wayback Machine
  28. ↑ "AmbySoft Inc. Coding Standards for Java v17.01d"
  29. ↑ Morelli, Brandon (17 November 2017). "5 JavaScript Style Guides – Including AirBnB, GitHub, & Google". codeburst.io. Retrieved 17 August 2018.
  30. ↑ "Variables".
  31. ↑ Naming conventions on CLiki
  32. ↑ Microsoft .NET Framework Capitalization Styles
  33. ↑ .NET Framework Developer's Guide – General Naming Conventions
  34. ↑ [Framework Design Guidelines, Krzysztof Cwalina, Brad Abrams Page 62]
  35. ↑ Modula-2 Name Convention
  36. ↑ Foreign API Identifiers in Modula-2 Name Convention
  37. ↑ "पर्ल स्टाइल गाइड".
  38. ↑ "perlmodlib – constructing new Perl modules and finding existing ones".
  39. ↑ "PHP मानक सिफ़ारिशें".
  40. ↑ "PSR-1: Basic Coding Standard - PHP-FIG".
  41. ↑ Style Guide for Python Code PEP8
  42. ↑ Style Guide for RCode
  43. ↑ "General rules of Perl 6 syntax".
  44. ↑ "नामकरण की परंपरा". doc.rust-lang.org (in English). Retrieved 4 February 2018.
  45. ↑ "स्विफ्ट.ओआरजी एपीआई डिज़ाइन दिशानिर्देश".


बाहरी संबंध

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=नेमिंग_कन्वेंशन_(प्रोग्रामिंग)&oldid=267794’