नेमिंग कन्वेंशन (प्रोग्रामिंग): Difference between revisions
m (Arti Shah moved page नामकरण परंपरा (प्रोग्रामिंग) to नेमिंग कन्वेंशन (प्रोग्रामिंग) without leaving a redirect) |
m (8 revisions imported from alpha:नेमिंग_कन्वेंशन_(प्रोग्रामिंग)) |
||
(6 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|Set of rules for naming entities in source code and documentation}} | {{Short description|Set of rules for naming entities in source code and documentation}} | ||
[[कंप्यूटर प्रोग्रामिंग]] में, '''नेमिंग कन्वेंशन''' आइडेंटिफायर (कंप्यूटर लैंग्वेज) के लिए उपयोग किए जाने वाले वर्ण अनुक्रम को चुनने के लिए नियमों का सेट है जो सोर्स कोड और [[सॉफ़्टवेयर दस्तावेज़ीकरण|सॉफ़्टवेयर डॉक्यूमेंटेशन]] में [[चर (कंप्यूटर विज्ञान)|वेरिएबल (कंप्यूटर विज्ञान)]], [[डेटा प्रकार|डेटा टाइप]], [[सबरूटीन|फंक्शन]] और अन्य इकाइयो को दर्शाता है। | |||
[[कंप्यूटर प्रोग्रामिंग]] में, | |||
नेमिंग कन्वेंशन का उपयोग करने के कारणों ([[प्रोग्रामर]] को किसी भी वर्ण अनुक्रम को चुनने की अनुमति देने के विपरीत) में निम्नलिखित सम्मिलित हैं: | |||
* | * सोर्स कोड को पढ़ने और समझने के लिए आवश्यक प्रयास को कम करने के लिए;<ref>Derek M. Jones [http://www.knosof.co.uk/cbook/oprandname.pdf "Operand names influence operator precedence decisions"] An experiment investigating the effect of variable names on operator precedence selection</ref> | ||
* सिंटैक्स और | * सिंटैक्स और नेमिंग स्टैण्डर्ड से अधिक महत्वपूर्ण उद्देश्यों पर ध्यान केंद्रित करने के लिए कोड समीक्षाओं को सक्षम करना है। | ||
* कोड गुणवत्ता समीक्षा टूल को अपनी रिपोर्टिंग को मुख्य रूप से सिंटैक्स और | * कोड गुणवत्ता समीक्षा टूल को अपनी रिपोर्टिंग को मुख्य रूप से सिंटैक्स और स्टाइल प्राथमिकताओं के अतिरिक्त अन्य महत्वपूर्ण उद्देश्यों पर केंद्रित करने में सक्षम बनाना है। | ||
नेमिंग कन्वेंशन का चुनाव अत्यंत विवादास्पद विषय हो सकता है, जिसमें प्रत्येक पक्षकार अपने को सर्वोत्तम और दूसरों को निम्नतर मानते हैं। बोलचाल की लैंग्वेज में इसे [[हठधर्मिता]] की स्थिति कहा जाता है।<ref>{{cite encyclopedia |last=Raymond |first=Eric S. |author-link=Eric S. Raymond |encyclopedia=The [[Jargon File]] |title=धार्मिक मुद्दे|url=http://www.catb.org/jargon/html/R/religious-issues.html |access-date=7 November 2011 |edition=version 4.4.8 |date=1 October 2004}}</ref> विभिन्न कंपनियों ने अपने स्वयं के कन्वेंशन का सेट भी स्थापित किया है। | |||
==संभावित लाभ== | ==संभावित लाभ== | ||
नेमिंग कन्वेंशन के लाभों में निम्नलिखित सम्मिलित हो सकते हैं: | |||
* पहचानकर्ता के उपयोग के बारे में अतिरिक्त जानकारी ( | * पहचानकर्ता के उपयोग के बारे में अतिरिक्त जानकारी (अतिरिक्त, [[ मेटा डेटा |मेटा डेटा]] ) प्रदान करना है; | ||
* अपेक्षाओं को औपचारिक बनाने और विकास टीम के | * अपेक्षाओं को औपचारिक बनाने और विकास टीम के अन्दर निरंतरता को बढ़ावा देने में सहायता करना है; | ||
* | * आटोमेटेड रीफैक्टरिंग के उपयोग को सक्षम करने या त्रुटि की न्यूनतम संभावना वाले टूल को खोजने और परिवर्तित करने के लिए; | ||
* संभावित अस्पष्टता के | * संभावित अस्पष्टता के स्थितियों में स्पष्टता बढ़ाने के लिए; | ||
* | * वर्क प्रोडक्ट के सौंदर्य और व्यावसायिक स्वरूप को बढ़ाने के लिए (उदाहरण के लिए, अत्यधिक बड़े नामों, हास्यप्रद या प्यारे नामों या संक्षिप्ताक्षरों की अनुमति न देकर); | ||
* विभिन्न संगठनों के | * विभिन्न संगठनों के वर्क प्रोडक्ट को संयोजित करने पर होने वाले नेमिंग कोलिसन से बचने में सहायता के लिए (यह भी देखें: [[नामस्थान|नेमस्पेस]]); | ||
* प्रोजेक्ट हैंडओवर में उपयोग के लिए सार्थक डेटा प्रदान करना जिसके लिए प्रोग्राम सोर्स कोड और सभी | * प्रोजेक्ट हैंडओवर में उपयोग के लिए सार्थक डेटा प्रदान करना जिसके लिए प्रोग्राम सोर्स कोड और सभी रिलेवेंट डॉक्यूमेंट एकत्र करने की आवश्यकता होती है; | ||
* | * बड़े समय के अंतराल के पश्चात कोड के पुन: उपयोग के स्थिति में उत्तम समझ प्रदान करना है। | ||
==चुनौतियाँ== | ==चुनौतियाँ== | ||
नेमिंग कन्वेंशन का चुनाव (और जिस सीमा तक उन्हें प्रयुक्त किया जाता है) अधिकांशतः विवादास्पद विषय होता है, जिसमें पक्षपाती अपने दृष्टिकोण को सर्वश्रेष्ठ और दूसरों को निम्नतर मानते हैं। इसके अतिरिक्त, ज्ञात और अच्छी तरह से परिभाषित नेमिंग कन्वेंशन के अतिरिक्त, कुछ संगठन निरंतर उनका पालन करने में विफल हो सकते हैं, जिससे असंगतता और भ्रम उत्पन्न हो सकता है। यदि नेमिंग कन्वेंशन के नियम आंतरिक रूप से असंगत, इच्छानुसार, याद रखने में कठिन, या अन्यथा लाभकारी से अधिक भारयुक्त माने जाते हैं, तो यह चुनौतियाँ और भी बढ़ सकती हैं। | |||
==पठनीयता== | ==पठनीयता== | ||
अच्छी तरह से चुने गए | अच्छी तरह से चुने गए आइडेंटिफायर डेवलपर्स और विश्लेषकों के लिए यह समझना अधिक सरल बनाते हैं कि सिस्टम क्या कर रहा है और नई आवश्यकताओ के लिए आवेदन करने के लिए सोर्स कोड को कैसे ठीक या विस्तारित किया जाता है। | ||
उदाहरण के लिए, यद्यपि | उदाहरण के लिए, यद्यपि | ||
Line 34: | Line 33: | ||
a = b * c; | a = b * c; | ||
</syntaxhighlight> | </syntaxhighlight> | ||
क्या [[सिंटैक्स (प्रोग्रामिंग भाषाएँ)]] सही है, इसका उद्देश्य स्पष्ट नहीं है। इसकी तुलना इससे करें: | क्या [[सिंटैक्स (प्रोग्रामिंग भाषाएँ)|सिंटैक्स (प्रोग्रामिंग लैंग्वेज)]] सही है, इसका उद्देश्य स्पष्ट नहीं है। इसकी तुलना इससे करें: | ||
<syntaxhighlight lang="C"> | <syntaxhighlight lang="C"> | ||
weekly_pay = hours_worked * hourly_pay_rate; | weekly_pay = hours_worked * hourly_pay_rate; | ||
</syntaxhighlight> | </syntaxhighlight> | ||
जो | जो सोर्स कोड के उद्देश्य और अर्थ को दर्शाता है, कम से कम उन लोगों के लिए जो कथन के संदर्भ से परिचित हैं। | ||
प्रयोगों से पता चलता है कि | प्रयोगों से पता चलता है कि आइडेंटिफायर स्टाइल रिकॉल और स्पष्टता को प्रभावित करती है और स्टाइल से परिचित होने से रिकॉल की गति तेज हो जाती है।<ref>{{Cite book |last1=Binkley |first1=Dave |last2=Davis |first2=Marcia |title=2009 IEEE 17th International Conference on Program Comprehension |chapter=To camelcase or under_score |date=2009 |chapter-url=http://www.cs.loyola.edu/~binkley/papers/icpc09-clouds.pdf |issue=17 |pages=158–167 |doi=10.1109/ICPC.2009.5090039|isbn=978-1-4244-3998-0 |s2cid=1450798 }} | ||
</ref> | </ref> | ||
== | ==कॉमन एलिमेंट== | ||
नेमिंग कन्वेंशन के स्पष्ट नियम उस संदर्भ पर निर्भर करते हैं जिसमें उनका उपयोग किया जाता है। फिर भी, ऐसे विभिन्न कॉमन एलिमेंट हैं जो आज सामान्य उपयोग में आने वाली सभी नेमिंग कन्वेंशन को नहीं तो सबसे अधिक प्रभावित करते हैं। | |||
===पहचानकर्ताओं की लंबाई=== | ===पहचानकर्ताओं की लंबाई=== | ||
सभी | सभी नेमिंग कन्वेंशन के मौलिक एलिमेंट पहचानकर्ता की लंबाई (अतिरिक्त, पहचानकर्ता में अनुमत व्यक्तिगत वर्णों की सीमित संख्या) से संबंधित नियम हैं। कुछ नियम निश्चित संख्यात्मक सीमा निर्धारित करते हैं, जबकि अन्य कम स्पष्ट अनुमान या दिशानिर्देश निर्दिष्ट करते हैं। | ||
पहचानकर्ता लंबाई नियमों का व्यवहार में नियमित रूप से विरोध किया जाता है, और | पहचानकर्ता लंबाई नियमों का व्यवहार में नियमित रूप से विरोध किया जाता है, और शैक्षिक रूप से बहुत विचार का विषय होता है। | ||
कुछ विचार: | कुछ विचार: | ||
* छोटे पहचानकर्ताओं को अधिक | * छोटे पहचानकर्ताओं को अधिक उपयुक्त के रूप में प्राथमिकता दी जा सकती है, क्योंकि उन्हें टाइप करना सरल होता है (चूंकि विभिन्न आईडीई और टेक्स्ट-एडिटर टेक्स्ट-पूर्णता प्रदान करते हैं, जो इसे कम करता है) | ||
* अत्यंत संक्षिप्त पहचानकर्ता (जैसे कि 'i' या 'j') को स्वचालित खोज और प्रतिस्थापन टूल का उपयोग करके विशिष्ट रूप से | * अत्यंत संक्षिप्त पहचानकर्ता (जैसे कि 'i' या 'j') को स्वचालित खोज और प्रतिस्थापन टूल का उपयोग करके विशिष्ट रूप से पृथक करना बहुत कठिन है (चूंकि यह [[नियमित अभिव्यक्ति|नियमित]] रेगेक्स-बेस्ड टूल के लिए कोई समस्या नहीं है) | ||
* | * बड़े पहचानकर्ताओं को प्राथमिकता दी जा सकती है क्योंकि छोटे पहचानकर्ता पर्याप्त जानकारी को एन्कोड नहीं कर सकते हैं या बहुत अलौकिक दिखाई देते हैं | ||
* दृश्य अव्यवस्था के कारण | * दृश्य अव्यवस्था के कारण बड़े पहचानकर्ताओं को नापसंद किया जा सकता है | ||
यह | यह विवृत शोध विषय है कि क्या कुछ प्रोग्रामर छोटे पहचानकर्ताओं को पसंद करते हैं क्योंकि उन्हें बड़े पहचानकर्ताओं की तुलना में टाइप करना या सोचना सरल होता है, या क्योंकि विभिन्न स्थितियों में बड़े पहचानकर्ता केवल दृश्यमान कोड को अव्यवस्थित करता है और कोई अतिरिक्त लाभ नहीं देता है। | ||
प्रोग्रामिंग में संक्षिप्तता का कुछ | प्रोग्रामिंग में संक्षिप्तता का कुछ सीमा तक कारण यह हो सकता है: | ||
* प्रारंभिक [[लिंकर (कंप्यूटिंग)]] जिसमें मेमोरी को बचाने के लिए वेरिएबल नामों को 6 अक्षरों तक सीमित करना आवश्यक था। | * प्रारंभिक [[लिंकर (कंप्यूटिंग)]] जिसमें मेमोरी को बचाने के लिए वेरिएबल नामों को 6 अक्षरों तक सीमित करना आवश्यक था। इसके पश्चात की प्रगति ने मानवीय समझ के लिए बड़े परिवर्तनशील नामों का उपयोग करने की अनुमति दी थी, किन्तु जहां केवल पहले कुछ अक्षर ही महत्वपूर्ण थे। [[ बुनियादी |मूलभूत]] के कुछ संस्करणों जैसे टीआरएस-80 लेवल 2 बेसिक में, बड़े नामों की अनुमति थी, किन्तु केवल पहले दो अक्षर ही महत्वपूर्ण थे। इस सुविधा ने गलत व्यवहार की अनुमति दी जिसे डीबग करना कठिन हो सकता है, उदाहरण के लिए जब VALUE और VAT जैसे नामों का उपयोग किया गया था और पृथक होने का आशय था। | ||
* प्रारंभिक [[स्रोत कोड संपादक]] | * प्रारंभिक [[स्रोत कोड संपादक|सोर्स कोड एडिटर]] में [[स्वत: पूर्ण]]ता का अभाव है | ||
* प्रारंभिक | * प्रारंभिक लो-रिज़ॉल्यूशन मॉनिटर सीमित लाइन लंबाई के साथ (उदाहरण के लिए केवल 80 अक्षर) | ||
* कंप्यूटर विज्ञान का अधिकांश भाग गणित से उत्पन्न हुआ है, जहां | * कंप्यूटर विज्ञान का अधिकांश भाग गणित से उत्पन्न हुआ है, जहां वरिएबल नाम परंपरागत रूप से केवल अक्षर होते हैं | ||
=== | ===लेटर केस और अंक=== | ||
कुछ | कुछ नेमिंग कन्वेंशन यह सीमित करती हैं कि लेटर अपरकेस या लोअरकेस में दिखाई दे सकते हैं या नहीं। अन्य कन्वेंशन लेटर स्थिति को प्रतिबंधित नहीं करतीं है, किन्तु अच्छी तरह से परिभाषित व्याख्या आधारित करती हैं लेटर स्थिति पर कुछ नेमिंग कन्वेंशन निर्दिष्ट करती हैं कि वर्णमाला, संख्यात्मक या अल्फ़ान्यूमेरिक वर्णों का उपयोग किया जा सकता है, और यदि हां, तो किस क्रम में आदि। | ||
वर्णों का उपयोग किया जा सकता है, और यदि हां, तो किस क्रम | |||
===एकाधिक-[[शब्द]] पहचानकर्ता=== | ===एकाधिक-[[शब्द]] पहचानकर्ता=== | ||
सामान्य अनुशंसा सार्थक पहचानकर्ताओं का उपयोग करना है। शब्द अनेक शब्दों जितना सार्थक या विशिष्ट नहीं हो सकता है। परिणाम स्वरुप, कुछ नेमिंग कन्वेंशन से अधिक शब्द वाले यौगिक पहचानकर्ताओं के उपचार के लिए नियम निर्दिष्ट करती हैं। | |||
चूंकि अधिकांश [[प्रोग्रामिंग भाषा]] | चूंकि अधिकांश [[प्रोग्रामिंग भाषा|प्रोग्रामिंग]] लैंग्वेज पहचानकर्ताओं में व्हाइटस्पेस (कंप्यूटर विज्ञान) की अनुमति नहीं देती हैं, इसलिए प्रत्येक शब्द को परिसीमित करने की विधि की आवश्यकता होती है (पश्चात् के पाठकों के लिए यह व्याख्या करना सरल हो जाता है कि कौन से अक्षर किस शब्द से संबंधित हैं)। ऐतिहासिक रूप से कुछ प्रारंभिक लैंग्वेज, विशेष रूप से [[फोरट्रान]] (1955) और एएलजीओएल (1958) ने, संदर्भ के अनुसार पहचानकर्ताओं के अंत का निर्धारण करते हुए, पहचानकर्ताओं के अन्दर रिक्त स्थान की अनुमति दी थी। टोकनाइजेशन (शब्दावली विश्लेषण) की कठिनाई के कारण पश्चात् की लैंग्वेज में इसे छोड़ दिया गया था। केवल शब्दों को जोड़कर नाम लिखना संभव है, और इसका उपयोग कभी-कभी किया जाता है, जैसे कि <code>mypackage</code> जावा पैकेज नामों के लिए,<ref>[https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html Naming a Package]</ref> चूंकि बड़े समय तक सुपाठ्यता प्रभावित होती है, इसलिए सामान्यतः किसी न किसी रूप में पृथक्करण का उपयोग किया जाता है। | ||
====सीमांकक-पृथक शब्द==== | ====सीमांकक-पृथक शब्द==== | ||
दृष्टिकोण [[अक्षरांकीय]] वर्ण के साथ पृथक-पृथक शब्दों को परिसीमित करना है। इस उद्देश्य के लिए सामान्यतः उपयोग किए जाने वाले दो लेटर [[हैफ़ेन]] (-) और [[ बल देना |अंडरस्कोर]] (_) हैं; उदाहरण के लिए, दो शब्दों वाला नाम<code>two words</code>के <code>two-words</code>या<code>two_words</code>रूप में दर्शाया जाएगा। | |||
हाइफ़न का उपयोग [[COBOL]] (1959), [[फोर्थ (प्रोग्रामिंग भाषा)]] (1970), और [[लिस्प (प्रोग्रामिंग भाषा)]] (1958) लिखने वाले लगभग सभी प्रोग्रामर द्वारा किया जाता है; यह [[यूनिक्स]] में कमांड और पैकेज के लिए भी | हाइफ़न का उपयोग [[COBOL|कोबोल]] (1959), [[फोर्थ (प्रोग्रामिंग भाषा)|फोर्थ (प्रोग्रामिंग लैंग्वेज)]] (1970), और [[लिस्प (प्रोग्रामिंग भाषा)|लिस्प (प्रोग्रामिंग लैंग्वेज)]] (1958) लिखने वाले लगभग सभी प्रोग्रामर द्वारा किया जाता है; यह [[यूनिक्स]] में कमांड और पैकेज के लिए भी सामान्य है, और इसका उपयोग [[ व्यापक शैली पत्रक |कैस्केडिंग स्टाइल शीट्स]] में किया जाता है।<ref>{{cite web |title = सीएसएस संदर्भ|website = [[Mozilla Developer Network]] |url = https://developer.mozilla.org/en-US/docs/Web/CSS/Reference |access-date=2016-06-18}}</ref> इस कन्वेंशन का कोई स्टैण्डर्ड नाम नहीं है, चूंकि इसे लिस्प-केस या कोबोल-केस (पास्कल केस की तुलना करें), कबाब-केस, ब्रोचेट-केस या अन्य वेरिएंट के रूप में संदर्भित किया जा सकता है।<ref>{{Cite web | title = StackOverflow – What's the name for snake_case with dashes? | url = https://stackoverflow.com/questions/11273282/whats-the-name-for-snake-case-with-dashes }}</ref><ref>{{Cite web | title = Programmers – If this is camelCase what-is-this? | url = http://programmers.stackexchange.com/questions/104468/if-this-is-camelcase-what-is-this }}</ref><ref>{{Cite web | title = Camel_SNAKE-kebab | website = [[GitHub]] | url = https://github.com/qerub/camel-snake-kebab | date = September 2019 }}</ref><ref>[http://c2.com/cgi/wiki?UnderscoreVersusCapitalAndLowerCaseVariableNaming UnderscoreVersusCapitalAndLowerCaseVariableNaming]</ref> इनमें से, कबाब-केस, कम से कम 2012 का है,<ref>{{cite web |url=https://stackoverflow.com/posts/12273101/revisions |title=Revisions to jwfearn's answer to What's the name for dash-separated case? |date=5 September 2012 |author=jwfearn}}</ref> तब से कुछ मुद्रा प्राप्त की है।<ref>''Living Clojure'' (2015), by Carin Meier, [https://books.google.com/books?id=b4odCAAAQBAJ&pg=PA91 p. 91]</ref><ref>[https://lodash.com/docs#kebabCase lodash: kebabCase]</ref> | ||
इसके विपरीत, फोरट्रान/एएलजीओएल कन्वेंशन की लैंग्वेज, विशेष रूप से [[सी (प्रोग्रामिंग भाषा)|सी (प्रोग्रामिंग लैंग्वेज)]] और [[पास्कल (प्रोग्रामिंग भाषा)|पास्कल (प्रोग्रामिंग लैंग्वेज)]] वर्गों की लैंग्वेज, [[घटाव|सब्ट्रेक्शन]] [[ इन्फिक्स संकेतन |इन्फिक्स नोटेशन]] ऑपरेटर के लिए हाइफ़न का उपयोग करती थीं, और इसके चारों ओर रिक्त स्थान की आवश्यकता नहीं चाहती थीं (जैसा फ्री -फ़ॉर्म लैंग्वेज), पहचानकर्ताओं में इसके उपयोग को रोकना है। | |||
विकल्प अंडरस्कोर का उपयोग करना है; यह सी वर्ग (पायथन सहित) में सामान्य है, छोटे अक्षरों के साथ, उदाहरण के [[सी प्रोग्रामिंग भाषा|सी प्रोग्रामिंग]] लैंग्वेज (1978) में पाया जाता है, और इसे [[ साँप का मामला |स्नैक केस]] या स्नेल केस के रूप में जाना जाता है। अपरकेस के साथ अंडरस्कोर, जैसे कि अपर_केस में, सामान्यतः [[सी प्रीप्रोसेसर]] मैक्रोज़ के लिए उपयोग किया जाता है, इसलिए इसे मैक्रो_केस के रूप में जाना जाता है, और यूनिक्स में पर्यावरण वरिएबल के लिए, जैसे [[बैश (यूनिक्स शेल)]] में बैश_वर्जन के लिए उपयोग किया जाता है। कभी-कभी इसे सामान्यतः स्क्रिमिंग_स्नेक_केस (वैकल्पिक रूप से स्क्रिमिंग_स्नेक_केस) कहा जाता है। | |||
==== | ====लेटर केस-सेपरेटेड वार्ड==== | ||
{{See also|लेटर केस#स्पेसल केस स्टाइल}} | |||
अन्य दृष्टिकोण मध्यस्थ पूंजीकरण का उपयोग करके शब्द सीमाओं को संकेत करना है, जिसे कैमल केस, पास्कलकेस और विभिन्न अन्य नाम कहा जाता है, इस प्रकार <code>two words</code>जैसा क्रमशः <code>twoWords</code>या<code>TwoWords</code> रेंडरिंग किया जाता है. यह कन्वेंशन सामान्यतः पास्कल (प्रोग्रामिंग लैंग्वेज), [[जावा (प्रोग्रामिंग भाषा)|जावा (प्रोग्रामिंग लैंग्वेज)]], सी शार्प (प्रोग्रामिंग लैंग्वेज) या सी#, और [[ मूल दृश्य |मूल दृश्य]] में उपयोग किया जाता है। पहचानकर्ताओं में आरंभिक शब्दों का उपचार (उदाहरण के लिए [[XML|एक्सएमएल]] और [[HTTP|एचटीटीपी]] में)। <code>[[XMLHttpRequest]]</code>) भिन्न होता है। कुछ लोग निर्देश देते हैं कि उन्हें छोटा किया जाए (उदा. <code>XmlHttpRequest</code>) टाइपिंग, पठनीयता और [[पाठ विभाजन|सेगमेंटेशन]] को सरल बनाने के लिए, जबकि स्पष्टता के लिए उन्हें बड़े अक्षरों में छोड़ देते हैं (उदाहरण के लिए<code>XMLHTTPRequest</code>)। | |||
====एकाधिक-शब्द पहचानकर्ता प्रारूपों के उदाहरण==== | |||
{| class="wikitable" | {| class="wikitable" | ||
|+ | |+एकाधिक-शब्द पहचानकर्ता प्रारूप | ||
! | !फ़ॉर्मेटिंग | ||
! | !नाम(s) | ||
|- | |- | ||
|<code>twowords</code> | |<code>twowords</code> | ||
| | |फ़्लैटकेस<ref name=":0">{{Cite web|title=naming - What are the different kinds of cases?|url=https://stackoverflow.com/questions/17326185/what-are-the-different-kinds-of-cases|access-date=2020-08-16|website=Stack Overflow}}</ref><ref>{{Cite web|date=2018-03-20|title=A brief list of programming naming conventions|url=https://www.deanpugh.com/a-brief-list-of-programming-naming-conventions/|access-date=2020-08-16|website=deanpugh.com|language=en-GB}}</ref> | ||
|- | |- | ||
|<code>TWOWORDS</code> | |<code>TWOWORDS</code> | ||
| | |अपरकेस<ref name=":0" /> | ||
|- | |- | ||
|<code>twoWords</code> | |<code>twoWords</code> | ||
|( | |(लोअर) कैमलकेस, ड्रोमेडरीकेस | ||
|- | |- | ||
|<code>TwoWords</code> | |<code>TwoWords</code> | ||
| | |पास्कलकेस, अपरकैमलकेस, स्टडीलीकेस<ref>{{Cite web|title=PSR-1: Basic Coding Standard - PHP-FIG|url=https://www.php-fig.org/psr/psr-1/|access-date=2020-09-04|website=www.php-fig.org|language=en}}</ref> | ||
|- | |- | ||
|<code>two_words</code> | |<code>two_words</code> | ||
| | |स्नेक_केस, स्नेल_केस, पोथोले_केस | ||
|- | |- | ||
|<code>TWO_WORDS</code> | |<code>TWO_WORDS</code> | ||
| | |आल_कैप्स, स्क्रिमिंग_स्नेक_केस,<ref>{{Cite web |title=Naming conventions |url=https://doc.rust-lang.org/1.0.0/style/style/naming/README.html |access-date=2023-05-02 |website=doc.rust-lang.org}}</ref> मैक्रो_केस, कांस्टेंट_केस | ||
|- | |- | ||
|<code>two_Words</code> | |<code>two_Words</code> | ||
| | |कैमल_स्नेक_केस | ||
|- | |- | ||
|<code>Two_Words</code> | |<code>Two_Words</code> | ||
| | |पास्कल_स्नेक_केस, टाइटल_केस | ||
|- | |- | ||
|<code>two-words</code> | |<code>two-words</code> | ||
|[[Kebab case| | |[[Kebab case|कबाब-केस]], डैश-केस, लिस्प-केस, स्पाइनल-केस | ||
|- | |- | ||
|<code>TWO-WORDS</code> | |<code>TWO-WORDS</code> | ||
| | |ट्रेन-केस, कोबोल-केस, स्क्रिमिग-कबाब-केस | ||
|- | |- | ||
|<code>Two-Words</code> | |<code>Two-Words</code> | ||
| | |ट्रेन-केस,<ref name=":0" /> एचटीटीपी-हैडर-केस<ref name=":1">{{Cite web|title=camel-snake-kebab|url=https://clj-commons.org/camel-snake-kebab/|access-date=2020-08-16|website=camel-snake-kebab|language=en-US}}</ref> | ||
|} | |} | ||
==मेटाडेटा और हाइब्रिड कन्वेंशन== | ==मेटाडेटा और हाइब्रिड कन्वेंशन== | ||
कुछ | कुछ नेमिंग कन्वेंशन उन नियमों या आवश्यकताओं का प्रतिनिधित्व करती हैं जो आवश्यकताओं से परे हैं किसी विशिष्ट प्रोजेक्ट या समस्या डोमेन का, और इसके अतिरिक्त बड़ा प्रतिबिंबित करता है [[सॉफ़्टवेयर वास्तुशिल्प|सॉफ़्टवेयर आर्किटेक्चर]], अंतर्निहित प्रोग्रामिंग लैंग्वेज या अन्य प्रकार की क्रॉस-प्रोजेक्ट पद्धति द्वारा परिभाषित सिद्धांतों का व्यापक सेट है। | ||
किसी विशिष्ट प्रोजेक्ट या समस्या डोमेन का, और इसके | |||
[[सॉफ़्टवेयर वास्तुशिल्प]], अंतर्निहित प्रोग्रामिंग | |||
===[[हंगेरियन संकेतन]]=== | ===[[हंगेरियन संकेतन|हंगेरियन नोटेशन]]=== | ||
शायद सबसे प्रसिद्ध हंगेरियन नोटेशन है, जो अपने नाम में | शायद सबसे प्रसिद्ध हंगेरियन नोटेशन है, जो अपने नाम में वरिएबल के उद्देश्य (एप्स हंगेरियन) या [[ डेटा प्रकार |डेटा टाइप]] (सिस्टम हंगेरियन) को एन्कोड करता है।<ref>{{Cite news | url=http://www.joelonsoftware.com/articles/Wrong.html |title = गलत कोड बनाना गलत दिखना|newspaper = Joel on Software|date = 11 May 2005}}</ref> उदाहरण के लिए, वेरिएबल szName के लिए उपसर्ग sz संकेत करता है कि वेरिएबल नल-टर्मिनेटेड स्ट्रिंग है। | ||
=== | ===पोजिशनल नोटेशन=== | ||
बहुत कम (आठ अक्षर और उससे कम) के लिए उपयोग की जाने वाली | बहुत कम (आठ अक्षर और उससे कम) के लिए उपयोग की जाने वाली स्टाइल LCCIIL01 हो सकती है:, जहां एल.सी अनुप्रयोग (लेटर ऑफ क्रेडिट) होगा, सी कोबोल के लिए, IIL विशेष प्रक्रिया सबसेट के लिए, और 01 अनुक्रम संख्या होती है। | ||
इस प्रकार का | इस प्रकार का कन्वेंशन अभी भी [[ कार्य नियंत्रण भाषा |जेसीएल]] लैंग्वेज पर निर्भर मेनफ्रेम में सक्रिय उपयोग में है और इसे 8.3 (पीरियड सेपरेटर के साथ अधिकतम आठ अक्षर और उसके पश्चात् तीन अक्षर फ़ाइल प्रकार) एमएस-डॉस स्टाइल में भी देखा जाता है। | ||
=== | ===कम्पोजिट वर्ड स्कीम (लैंग्वेज ओएफ)=== | ||
आईबीएम की ओएफ लैंग्वेज को आईएमएस ([[सूचना प्रबंधन प्रणाली]]) मैनुअल में प्रलेखित किया गया था। | |||
इसमें प्राइम-मोडिफायर-क्लास | इसमें प्राइम-मोडिफायर-क्लास वर्ड योजना का विवरण दिया गया, जिसमें ग्राहक खाता संख्या को संकेत करने के लिए कस्टडी-एक्ट-नं जैसे नाम सम्मिलित थे। | ||
प्राइम वर्ड किसी सिस्टम में रुचि रखने वाली प्रमुख संस्थाओं को संकेत करने के लिए थे। | |||
अतिरिक्त परिशोधन, योग्यता और पठनीयता के लिए संशोधक शब्दों का प्रयोग किया | अतिरिक्त परिशोधन, योग्यता और पठनीयता के लिए संशोधक शब्दों का प्रयोग किया गया था। | ||
क्लास | क्लास वर्ड आदर्श रूप से किसी विशेष एप्लिकेशन के लिए प्रासंगिक डेटा प्रकारों की बहुत छोटी सूची होगी। सामान्य वर्ग के शब्द हो सकते हैं: NO (संख्या), ID (पहचानकर्ता), TXT (पाठ), AMT (राशि), QTY (मात्रा), FL (ध्वज), CD (कोड), W (कार्य) इत्यादि। व्यवहार में, उपलब्ध क्लास वर्ड दो दर्जन से कम शब्दों की सूची होगी। | ||
क्लास | क्लास वर्ड, सामान्यतः दाईं ओर (प्रत्यय) स्थित होते हैं, हंगेरियन नोटेशन उपसर्गों के समान ही उद्देश्य पूरा करते हैं। | ||
क्लास शब्दों का उद्देश्य, स्थिरता के | क्लास शब्दों का उद्देश्य, स्थिरता के अतिरिक्त, प्रोग्रामर को किसी विशेष डेटा फ़ील्ड के डेटा प्रकार को निर्दिष्ट करना था। बूलियन (केवल दो मान) फ़ील्ड की स्वीकृति से पहले, FL (ध्वज) केवल दो संभावित मानों वाले फ़ील्ड को संकेत करता है। | ||
== | ==लैंग्वेज-स्पेसिफिक कन्वेंशन== | ||
===[[एकमा स्क्रिप्ट]]=== | ===[[एकमा स्क्रिप्ट]]=== | ||
एडोब के कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास [[ ActionScript ]] के लिए | एडोब के कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास [[ ActionScript |एक्शनस्क्रिप्ट]] के लिए नेमिंग स्टैण्डर्ड का सुझाव देते हैं जो अधिकतर ईसीएमएस्क्रिप्ट के अनुरूप होते हैं।{{Citation needed|date=November 2011}} पहचानकर्ताओं की स्टाइल जावा (प्रोग्रामिंग लैंग्वेज) के समान है। | ||
===एडीए=== | |||
[[एडा (प्रोग्रामिंग भाषा)|एडा (प्रोग्रामिंग लैंग्वेज)]] में, पहचानकर्ताओं की एकमात्र अनुशंसित स्टाइल <code>Mixed_Case_With_Underscores</code> है .<ref>{{Cite web|url=http://www.adaic.org/resources/add_content/docs/95style/html/sec_3/3-2-1.html|title = 3.2.1 Names - Chapter 3 - Ada 95 QUALITY AND STYLE Guide}}</ref> | |||
===एपीएल=== | ===एपीएल=== | ||
[[एपीएल (प्रोग्रामिंग भाषा)]] बोलियों में, डेल्टा (Δ) का उपयोग शब्दों के बीच किया जाता है, जैसे PERFΔSQUARE (पुराने एपीएल संस्करणों में पारंपरिक रूप से कोई लोअरकेस | [[एपीएल (प्रोग्रामिंग भाषा)|एपीएल (प्रोग्रामिंग लैंग्वेज)]] बोलियों में, डेल्टा (Δ) का उपयोग शब्दों के बीच किया जाता है, जैसे PERFΔSQUARE (पुराने एपीएल संस्करणों में पारंपरिक रूप से कोई लोअरकेस उपस्थित नहीं था)। यदि नाम में अंडरस्कोर वाले अक्षरों का उपयोग किया गया है, तो इसके स्थान पर डेल्टा अंडरबार (⍙) का उपयोग किया जाता है। | ||
===सी और [[सी++]]=== | ===सी और [[सी++]]=== | ||
सी (प्रोग्रामिंग लैंग्वेज) और सी++ में, [[कीवर्ड (कंप्यूटर प्रोग्रामिंग)]] और स्टैण्डर्ड लाइब्रेरी आइडेंटिफायर अधिकतर लोअरकेस होते हैं। सी स्टैण्डर्ड लाइब्रेरी में, संक्षिप्त नाम सबसे सामान्य हैं (उदाहरण के लिए) <code>isalnum</code> किसी फ़ंक्शन के परीक्षण के लिए कि क्या कोई वर्ण अल्फ़ान्यूमेरिक है), जबकि सी++ स्टैण्डर्ड लाइब्रेरी अधिकांशतः शब्द विभाजक के रूप में अंडरस्कोर का उपयोग करती है (उदा. <code>out_of_range</code>). सी प्रीप्रोसेसर#मैक्रो परिभाषा और विस्तार का प्रतिनिधित्व करने वाले पहचानकर्ता, कन्वेंशन के अनुसार, केवल अपरकेस अक्षरों और अंडरस्कोर का उपयोग करके लिखे गए हैं (यह विभिन्न प्रोग्रामिंग लैंग्वेज में कांस्टेंट के लिए आल-अपर-केस पहचानकर्ताओं का उपयोग करने की कन्वेंशन से संबंधित है)। डबल अंडरस्कोर वाले या अंडरस्कोर और बड़े अक्षर से प्रारंभ होने वाले नाम कार्यान्वयन ([[ संकलक | कंपाइलर]] , स्टैण्डर्ड लाइब्रेरी) के लिए आरक्षित हैं और उनका उपयोग नहीं किया जाना चाहिए (उदाहरण के लिए<code>__reserved</code> या <code>_Reserved</code>) .<ref>{{Cite web | title = ISO/IEC 9899:1999 Programming languages – C | publisher = ISO | url = http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=29237}}</ref><ref>{{Cite web | title = ISO/IEC 14882:2011 Information technology – Programming languages – C++ | publisher = ISO | url = http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=50372}}</ref> यह सुपरफिसिअल्ली स्ट्रॉपिंग (वाक्यविन्यास) के समान है, किन्तु शब्दार्थ पृथक-पृथक हैं: अंडरस्कोर वर्णों को उद्धृत करने के अतिरिक्त पहचानकर्ता के मूल्य का भाग हैं (जैसा कि स्ट्रॉपिंग है): __foo का मान __foo है (जो आरक्षित है), foo नहीं (किन्तु एक पृथक नामस्थान में) | |||
===सी#=== | ===सी#=== | ||
सी शार्प (प्रोग्रामिंग | सी शार्प (प्रोग्रामिंग लैंग्वेज) या सी# नेमिंग कन्वेंशन सामान्यतः सभी .नेट लैंग्वेज के लिए माइक्रोसॉफ्ट द्वारा प्रकाशित दिशानिर्देशों का पालन करती हैं <ref>{{Cite web | title = नामकरण दिशानिर्देश| date = 15 September 2021 | publisher = Microsoft | url = https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions}}</ref> (नीचे .नेट अनुभाग देखें), किन्तु सी# कंपाइलर द्वारा कोई कन्वेंशन प्रयुक्त नहीं की जाती है। | ||
माइक्रोसॉफ्ट दिशानिर्देश केवल इसके विशेष उपयोग <code>[[CamelCase|PascalCase]]</code> और <code>[[camelCase|कैमलकेस]]</code> की अनुशंसा करते हैं ,इसके पश्चात् वाले का उपयोग केवल विधि पैरामीटर नामों और विधि-स्थानीय वरिएबल नामों (विधि-स्थानीय सहित <code>const</code> मान) के लिए किया जाता है । पास्कलकेस में विशेष अपवाद दो-अक्षर वाले संक्षिप्ताक्षरों के लिए बनाया गया है जो पहचानकर्ता प्रारंभ करते हैं; इन स्थितियों में, दोनों अक्षर बड़े अक्षरों में लिखे गए हैं (उदाहरण के लिए, <code>IOStream</code>); बड़े संक्षिप्त शब्दों (उदाहरण के लिए, <code>XmlStream</code>) के स्थिति में ऐसा नहीं है. दिशानिर्देश <code>interface</code> अनुशंसा करते हैं कि जो नाम <code>PascalCase</code> दिया गया है जिसके बड़े अक्षर से पहले <code>I</code>, जो जैसा कि <code>IEnumerable</code> | |||
में है। | |||
=== | फ़ील्ड नेमिंग के लिए माइक्रोसॉफ्ट दिशानिर्देश <code>static</code>, <code>public</code>, और <code>protected</code> के लिए विशिष्ट हैं; वे क्षेत्र जो <code>static</code> नहीं हैं और जिनमें अन्य पहुंच स्तर हैं (जैसे <code>internal</code> और <code>private</code>) स्पष्ट रूप से दिशानिर्देशों में शामिल नहीं हैं।<ref>{{Cite web | title = प्रकार सदस्यों के नाम| date = 15 September 2021 | publisher = Microsoft | url = https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members}}</ref> सबसे आम अभ्यास सभी फ़ील्ड के नामों के लिए <code>PascalCase</code> का उपयोग करना है, अतिरिक्त उन फ़ील्ड्स के जो <code>private</code> हैं (और न ही <code>const</code> और न <code>static</code>), जिन्हें ऐसे नाम दिए गए हैं जो एकल अंडरस्कोर से पहले <code>कैमलकेस</code> का उपयोग करते हैं; उदाहरण के लिए, <code>_totalCount है</code> | ||
किसी भी पहचानकर्ता नाम के पहले अर्थ में कोई परिवर्तन किए बिना वाणिज्यिक-एट प्रतीक (@) लगाया जा सकता है। अर्थात्, <code>factor</code> और <code>@factor</code> दोनों एक ही वस्तु को संदर्भित करते हैं। परंपरा के अनुसार, इस उपसर्ग का उपयोग केवल उन स्थितियों में किया जाता है जब पहचानकर्ता अन्यथा एक आरक्षित कीवर्ड (जैसे कि <code>for</code> और <code>while</code>) होगा, जिसे उपसर्ग के बिना पहचानकर्ता के रूप में उपयोग नहीं किया जा सकता है, या एक प्रासंगिक कीवर्ड (जैसे कि <code>from</code> और <code>where</code>) ), जिन स्थितियों में उपसर्ग की सख्ती से आवश्यकता नहीं है (कम से कम इसकी घोषणा पर नहीं; उदाहरण के लिए, चूंकि घोषणा <code>dynamic dynamic;</code>; वैध है, इसे सामान्यतः <code>dynamic dynamic;</code> के रूप में देखा जाएगा; पाठक को तुरंत इंगित करने के लिए कि पश्चात् वाला एक परिवर्तनीय नाम है)। | |||
=== | ===डार्ट/फ्लाटर=== | ||
फ़्लटर_(सॉफ़्टवेयर) में प्रयुक्त डार्ट_(प्रोग्रामिंग_लैंग्वेज) लैंग्वेज में, कन्वेंशन जावा के समान हैं, अतिरिक्त इसके कि कांस्टेंट लोअरकैमलकेस में लिखे गए हैं। डार्ट वाक्यात्मक नियम प्रयुक्त करता है कि गैर-स्थानीय आइडेंटिफायर अंडरस्कोर से प्रारंभ होते हैं (<code>_</code>) को निजी माना जाता है (चूंकि लैंग्वेज में सार्वजनिक या निजी पहुंच के लिए स्पष्ट कीवर्ड नहीं हैं)। इसके अतिरिक्त, सोर्स फ़ाइल नाम जावा के प्रति सोर्स फ़ाइल के सार्वजनिक वर्ग का पालन नहीं करते हैं, नाम नियम से मेल खाना चाहिए, इसके अतिरिक्त फ़ाइल नाम के लिए स्नैक_केस का उपयोग करें।<ref>{{Cite web | url=https://dart.dev/guides/language/effective-dart/style | title=Effective Dart - the Dart Style Guide}}</ref> | |||
===गो=== | |||
गो में, मल्टीवर्ड नाम लिखने के लिए अंडरस्कोर के अतिरिक्त <code>MixedCaps</code> या <code>mixedCaps</code> का उपयोग करने की परंपरा है। संरचनाओं या कार्यों का संदर्भ देते समय, पहला अक्षर बाहरी पैकेजों के लिए दृश्यता निर्दिष्ट करता है। पहला अक्षर अपरकेस बनाने से कोड का वह भाग निर्यात हो जाता है, जबकि लोअरकेस इसे केवल वर्तमान सीमा में ही प्रयोग करने योग्य बनाता है।<ref>{{Cite web | url=https://golang.org/doc/effective_go.html#mixed-caps | title=Effective Go - the Go Programming Language}}</ref> | |||
===जावा=== | ===जावा=== | ||
जावा (प्रोग्रामिंग | जावा (प्रोग्रामिंग लैंग्वेज) में, पहचानकर्ताओं के लिए नेमिंग कन्वेंशन विभिन्न जावा कम्युनिटी जैसे सन माइक्रोसिस्टम्स, द्वारा स्थापित और सुझाई गई हैं।<ref name="SunJavaCodeConv">"Code Conventions for the Java Programming Language", [http://java.sun.com/docs/codeconv/html/CodeConventions.doc8.html Section 9: "Naming Conventions"]</ref> नेटस्केप,<ref>"NETSCAPE'S SOFTWARE CODING STANDARDS GUIDE FOR JAVA",[http://collaboratory.emsl.pnl.gov/docs/collab/sam/CodeStandards.html Collab Software Coding Standards Guide for Java] {{Webarchive|url=https://web.archive.org/web/20090303185605/http://collaboratory.emsl.pnl.gov/docs/collab/sam/CodeStandards.html |date=3 March 2009 }}</ref> एम्बीसॉफ्ट,<ref>[http://www.ambysoft.com/essays/javaCodingStandards.html "AmbySoft Inc. Coding Standards for Java v17.01d"]</ref> आदि। सन माइक्रोसिस्टम्स द्वारा निर्धारित नेमिंग कन्वेंशन का प्रारूप नीचे सूचीबद्ध है, | ||
जहां | |||
जहां कैमलकेस में नाम बिना रिक्त स्थान के जुड़े हुए विभिन्न शब्दों से बना है, प्रत्येक शब्द का - पहले शब्द को छोड़कर - बड़े अक्षरों में प्रारंभिक अक्षर है - उदाहरण के लिए कैमलकेस है। | |||
{| class="wikitable" border="1" | {| class="wikitable" border="1" | ||
|- | |- | ||
! | ! पहचानकर्ता का प्रकार | ||
! | ! नेमिंग के नियम | ||
! | ! उदाहरण | ||
|- | |- | ||
| | | क्लासेस | ||
| | | कक्षा के नाम अपरकैमलकेस में संज्ञा होने चाहिए, प्रत्येक शब्द का पहला अक्षर बड़े अक्षरों में होना चाहिए। पूरे शब्दों का उपयोग करें - संक्षिप्ताक्षरों से बचें (जब तक कि संक्षिप्ताक्षर बड़े रूप की तुलना में अधिक व्यापक रूप से उपयोग नहीं किया जाता है, जैसे कि यूआरएल या एचटीएमएल)। | ||
| | | | ||
* <code>class Raster {}</code> | * <code>class Raster {}</code> | ||
* <code>class ImageSprite {}</code> | * <code>class ImageSprite {}</code> | ||
|- | |- | ||
| | | विधियाँ | ||
| | | विधियाँ लोअरकेमलकेस में क्रिया होनी चाहिए या एक बहु-शब्द नाम जो लोअरकेस में एक क्रिया से प्रारंभ होता है; यह अपरकेस में पहले अक्षर लोअरकेस और इसके पश्चात के शब्दों के पहले अक्षर के साथ है। | ||
| | | | ||
* <code>run();</code> | * <code>run();</code> | ||
* <code>runFast();</code> | * <code>runFast();</code> | ||
* <code>getBackground();</code> | * <code>getBackground();</code> | ||
|- | |- | ||
| | |वैरिएबल | ||
| | |स्थानीय वैरिएबल, इंस्टेंस वैरिएबल और क्लास वैरिएबल भी लोअरकैमलकेस में लिखे गए हैं। परिवर्तनीय नाम अंडरस्कोर (_) या डॉलर चिह्न ($) वर्णों से प्रारंभ नहीं होने चाहिए, तथापि दोनों की अनुमति हो। यह अन्य कोडिंग कन्वेंशन के विपरीत है जो बताती है कि सभी इंस्टेंस वेरिएबल्स को उपसर्ग करने के लिए अंडरस्कोर का उपयोग किया जाना चाहिए। | ||
परिवर्तनीय नाम छोटे किन्तु अर्थपूर्ण होने चाहिए। एक परिवर्तनीय नाम का चुनाव स्मरणीय होना चाहिए - अर्थात, आकस्मिक पर्यवेक्षक को इसके उपयोग के उद्देश्य को इंगित करने के लिए डिज़ाइन किया गया है। अस्थायी "थ्रोअवे" वेरिएबल को छोड़कर एक-वर्ण वाले वेरिएबल नामों से बचना चाहिए। अस्थायी वैरिएबल के सामान्य नाम पूर्णांकों के लिए i, j, k, m, और n हैं; वर्णों के लिए c, d, और e। | |||
| | | | ||
* <code>int i;</code> | * <code>int i;</code> | ||
* <code>char | * <code>char सी;</code> | ||
* <code>float myWidth;</code> | * <code>float myWidth;</code> | ||
|- | |- | ||
| | |स्थिरांक | ||
| | |स्थिरांक को अंडरस्कोर द्वारा पृथक किए गए अपरकेस वर्णों में लिखा जाना चाहिए। यदि उपयुक्त हो तो निरंतर नामों में अंक भी हो सकते हैं, लेकिन पहले अक्षर के रूप में नहीं। | ||
| | | | ||
* {{code|2=java|1=static final int MAX_PARTICIPANTS = 10;}} | * {{code|2=java|1=static final int MAX_PARTICIPANTS = 10;}} | ||
|} | |} | ||
जावा कंपाइलर इन नियमों को | जावा कंपाइलर इन नियमों को प्रयुक्त नहीं करते हैं, किन्तु उनका पालन करने में विफल रहने से भ्रम और गलत कोड हो सकता है। उदाहरण के लिए, <code>widget.expand()</code> और <code>Widget.expand()</code> महत्वपूर्ण रूप से भिन्न व्यवहार दर्शाते हैं: <code>widget.expand()</code> विधि के आह्वान का तात्पर्य है <code>expand()</code> नामक उदाहरण में <code>widget</code>, जबकि <code>Widget.expand()</code> स्थैतिक विधि के आह्वान का तात्पर्य <code>expand()</code> कक्षा में <code>Widget</code> है. | ||
एक व्यापक रूप से उपयोग की जाने वाली जावा कोडिंग स्टाइल यह निर्देश देती है कि <code>[[CamelCase|UpperCamelCase]]</code> का उपयोग कक्षाओं के लिए किया जाना चाहिए और <code>[[CamelCase|lowerCamelCase]]</code> का उपयोग उदाहरणों और विधियों के लिए किया जाना चाहिए। <ref name="SunJavaCodeConv" /> इस उपयोग को पहचानते हुए, कुछ आईडीई, जैसे एक्लिप्स, कैमलकेस पर आधारित शॉर्टकट प्रयुक्त करते हैं। उदाहरण के लिए, एक्लिप्स की सामग्री सहायता सुविधा में, कैमलकेस शब्द के केवल बड़े अक्षरों को टाइप करने से कोई भी मिलान वर्ग या विधि का नाम सुझाया जाएगा (उदाहरण के लिए, "एनपीई" टाइप करना और सामग्री सहायता को सक्रिय करना <code>NullPointerException</code> का सुझाव दे सकता है)। | |||
व्यापक रूप से उपयोग की जाने वाली जावा कोडिंग | |||
तीन या अधिक अक्षरों के प्रथमाक्षर अपरकेस के | तीन या अधिक अक्षरों के प्रथमाक्षर अपरकेस के अतिरिक्त कैमलकेस हैं (जैसे, <code>parseDbmXmlFromIPAddress</code> के अतिरिक्त <code>parseDBMXMLFromIPAddress</code>). कोई व्यक्ति दो या अधिक अक्षरों पर भी सीमा निर्धारित कर सकता है (उदा. <code>parseDbmXmlFromIpAddress</code>). | ||
===जावास्क्रिप्ट=== | ===जावास्क्रिप्ट=== | ||
अंतर्निहित जावास्क्रिप्ट लाइब्रेरीज़ जावा के समान | अंतर्निहित जावास्क्रिप्ट लाइब्रेरीज़ जावा के समान नेमिंग कन्वेंशन का उपयोग करती हैं। डेटा प्रकार और कंस्ट्रक्टर फ़ंक्शन अपर कैमल केस (<code>RegExp</code>, <code>TypeError</code>, <code>XMLHttpRequest</code>, <code>DOMObject</code>) का उपयोग करते हैं और विधियां लोअर कैमल केस (<code>getElementById</code>, <code>getElementsByTagNameNS</code>, <code>createCDATASection</code>) का उपयोग करते हैं। सुसंगत रहने के लिए अधिकांश जावास्क्रिप्ट डेवलपर इन कन्वेंशन का पालन करते हैं। <ref>{{cite web|url=https://codeburst.io/5-javascript-style-guides-including-airbnb-github-google-88cbc6b2b7aa|title=5 JavaScript Style Guides – Including AirBnB, GitHub, & Google|last1=Morelli|first1=Brandon|date=17 November 2017|website=codeburst.io|access-date=17 August 2018}}</ref> यह भी देखें: [https://www.crockford.com/code.html डगलस क्रॉकफोर्ड के कन्वेंशन] | ||
यह भी देखें: [https://www.crockford.com/code.html डगलस क्रॉकफोर्ड के | |||
===लिस्प=== | ===लिस्प=== | ||
अधिकांश लिस्प (प्रोग्रामिंग | अधिकांश लिस्प (प्रोग्रामिंग लैंग्वेज) बोलियों में सामान्य अभ्यास पहचानकर्ताओं में शब्दों को पृथक करने के लिए डैश का उपयोग करना है, जैसा कि <code>with-open-file</code> और <code>make-hash-table</code>. डायनामिक वरिएबल नाम परंपरागत रूप से तारांकन <code>*map-walls*</code>. के साथ प्रारंभ और समाप्त होते हैं: स्थिरांकों के नाम धन चिह्न <code>+map-size+</code> से चिह्नित होते हैं: .<ref>{{Cite web | url=http://www.gigamonkeys.com/book/variables.html |title = Variables}}</ref><ref>[http://www.cliki.net/Naming+conventions Naming conventions] on [[CLiki]]</ref> | ||
===.नेट=== | |||
माइक्रोसॉफ्ट .नेट अधिकांश पहचानकर्ताओं के लिए <code>[[CamelCase|UpperCamelCase]]</code> अनुशंसा करता है , जिसे पास्कलकेस के रूप में भी जाना जाता है। (<code>[[CamelCase|lowerCamelCase]]</code> [[पैरामीटर (कंप्यूटर विज्ञान)]] और वरिएबल [[ चर (प्रोग्रामिंग) |(प्रोग्रामिंग)]] ) के लिए अनुशंसित है और यह .नेट लैंग्वेज के लिए साझा कन्वेंशन है।<ref>[http://msdn.microsoft.com/en-us/library/ms229043.aspx Microsoft .NET Framework Capitalization Styles]</ref> माइक्रोसॉफ्ट आगे अनुशंसा करता है कि किसी भी प्रकार के उपसर्ग संकेत (जिसे हंगेरियन नोटेशन के रूप में भी जाना जाता है) का उपयोग नहीं किया जाता है।<ref>[http://msdn.microsoft.com/en-us/library/ms229045.aspx .NET Framework Developer's Guide – General Naming Conventions]</ref> हंगेरियन नोटेशन का उपयोग करने के अतिरिक्त नाम को बेस क्लास <code>LoginButton</code> के अतिरिक्त <code>BtnLogin</code> के नाम से समाप्त करने की अनुशंसा की जाती है;<ref>[Framework Design Guidelines, Krzysztof Cwalina, Brad Abrams Page 62]</ref> | |||
===ऑब्जेक्टिव-सी=== | |||
[[ उद्देश्य सी | ऑब्जेक्टिव सी]] की सामान्य कोडिंग स्टाइल है जिसकी जड़ें स्मॉलटॉक में हैं। | |||
शीर्ष-स्तरीय इकाइयाँ, जिनमें कक्षाएं, प्रोटोकॉल, श्रेणियाँ, साथ ही सी निर्माण सम्मिलित हैं, जिनका उपयोग वैश्विक वरिएबल और फ़ंक्शंस जैसे ऑब्जेक्टिव-सी प्रोग्रामो में किया जाता है, अपरकैमलकेस में नेमस्पेस को दर्शाते हुए छोटे ऑल-अपरकेस उपसर्ग के साथ हैं, जैसे <code>NSString</code>, <code>UIAppDelegate</code>, <code>NSApp</code> या <code>CGRectMake</code>. कांस्टेंट को वैकल्पिक रूप से छोटे अक्षर k जैसे उपसर्ग <code>kCFBooleanTrue</code> के साथ जोड़ा जा सकता है . | |||
किसी ऑब्जेक्ट के इंस्टेंस वेरिएबल लोअरकैमलकेस का उपयोग करते हैं जो अंडरस्कोर के साथ उपसर्ग होता है, जैसे <code>_delegate</code> और <code>_tableView</code> है | |||
विधि नाम कोलन द्वारा पृथक किए गए विभिन्न लोअरकैमलकेस भागों का उपयोग करते हैं जो नियमो को सीमित करते हैं, जैसे: <code>application:didFinishLaunchingWithOptions:</code>, <code>stringWithFormat:</code> और <code>isRunning</code>. | |||
विधि नाम कोलन द्वारा | |||
===पास्कल, मोडुला-2 और ओबेरॉन=== | ===पास्कल, मोडुला-2 और ओबेरॉन=== | ||
विर्थियन | विर्थियन लैंग्वेज सामान्यतः पास्कल, मोडुला-2 और ओबेरॉन <code>Capitalized</code> या <code>UpperCamelCase</code> का उपयोग करते हैं प्रोग्राम, मॉड्यूल, कांस्टेंट, प्रकार और प्रक्रियाओं के लिए पहचानकर्ता, और <code>lowercase</code> या <code>lowerCamelCase</code> गणित कांस्टेंट, वैरिएबल, औपचारिक पैरामीटर और फ़ंक्शन के लिए पहचानकर्ता है।<ref>[http://modula-2.info/m2r10/pmwiki.php/Recommendations/NameConvention#Identifiers Modula-2 Name Convention]</ref> जबकि कुछ बोलियाँ पहचानकर्ताओं में अंडरस्कोर और डॉलर संकेतों का समर्थन करती हैं, स्नेक केस और मैक्रो केस विदेशी एपीआई इंटरफेस के अन्दर उपयोग तक ही सीमित हैं।<ref>[http://modula-2.info/m2r10/pmwiki.php/Recommendations/NameConvention#ForeignAPIIdentifiers Foreign API Identifiers in Modula-2 Name Convention]</ref> | ||
===[[पर्ल]]=== | ===[[पर्ल]]=== | ||
पर्ल | पर्ल कन्वेंशन के लिए अपनी सी विरासत से कुछ संकेत लेता है। स्थानीय रूप से स्कोप्ड वेरिएबल और सबरूटीन नाम इनफ़िक्स अंडरस्कोर के साथ लोअरकेस में हैं। प्राइवेट माने जाने वाले सबरूटीन्स और वेरिएबल्स के पहले अंडरस्कोर लगा होता है। पैकेज वेरिएबल शीर्षक आवरण वाले हैं। घोषित कांस्टेंट सभी अधिकतम सीमाएँ हैं। प्राग्माटा को छोड़कर पैकेज के नाम कैमल केस हैं—उदाहरण के लिए, <code>strict</code> और <code>[[C3 linearization|mro]]</code>-जो लोअरकेस हैं।<ref>{{Cite web | title = पर्ल स्टाइल गाइड| url = http://perldoc.perl.org/perlstyle.html }}</ref><ref>{{Cite web | title = perlmodlib – constructing new Perl modules and finding existing ones | url = http://perldoc.perl.org/perlmodlib.html }}</ref> | ||
<ref>{{Cite web | title = पर्ल स्टाइल गाइड| url = http://perldoc.perl.org/perlstyle.html }}</ref> | |||
<ref>{{Cite web | title = perlmodlib – constructing new Perl modules and finding existing ones | url = http://perldoc.perl.org/perlmodlib.html }}</ref> | |||
===[[पीएचपी]]=== | ===[[पीएचपी]]=== | ||
पीएचपी पक्ष समर्थन पीएसआर-1 (पीएचपी स्टैण्डर्ड पक्ष समर्थन 1) और पीएसआर-12 में सम्मिलित हैं।<ref name=PSR>{{Cite web | title = PHP मानक सिफ़ारिशें| url = http://www.php-fig.org/psr/}}</ref> पीएसआर-1 के अनुसार, क्लास के नाम पास्कलकेस में होने चाहिए, क्लास कांस्टेंट मैक्रो_केस में होने चाहिए, और फ़ंक्शन और विधि के नाम कैमलकेस में होने चाहिए।<ref>{{Cite web|url=https://www.php-fig.org/psr/psr-1/|title = PSR-1: Basic Coding Standard - PHP-FIG}}</ref> | |||
=== पायथन और रूबी === | === पायथन और रूबी === | ||
[[पायथन (प्रोग्रामिंग भाषा)]] और [[रूबी (प्रोग्रामिंग भाषा)]] दोनों | [[पायथन (प्रोग्रामिंग भाषा)|पायथन (प्रोग्रामिंग लैंग्वेज)]] और [[रूबी (प्रोग्रामिंग भाषा)|रूबी (प्रोग्रामिंग लैंग्वेज)]] दोनों वर्ग के नामों के लिए <code>UpperCamelCase</code>, स्थिरांक के लिए <code>CAPITALIZED_WITH_UNDERSCORES</code> और अन्य नामों के लिए <code>snake_case</code> की अनुशंसा करते हैं। | ||
पायथन में, यदि किसी नाम का उद्देश्य "प्राइवेट" होना है, तो उसके पहले या दो अंडरस्कोर लगाए जाते हैं (पायथन में यह कमोबेश हैक है)। निजी वरिएबल केवल कन्वेंशन द्वारा पायथन में प्रयुक्त किए जाते हैं। पायथन कीवर्ड के साथ कोलिसन को रोकने के लिए नामों के साथ अंडरस्कोर भी जोड़ा जा सकता है। डबल अंडरस्कोर के साथ उपसर्ग लगाने से नाम मैंगलिंग पायथन के संबंध में कक्षाओं में व्यवहार परिवर्तित हो जाता है। डबल अंडरस्कोर के साथ उपसर्ग और प्रत्यय - पायथन में तथाकथित डंडर (डबल अंडर) विधियां - मैजिकल नेम के लिए आरक्षित हैं जो पायथन ऑब्जेक्ट्स में विशेष व्यवहार को पूरा करते हैं।<ref name=pep8>[https://www.python.org/dev/peps/pep-0008/ Style Guide for Python Code PEP8]</ref> | |||
=== आर === | === आर === | ||
जबकि [[आर (प्रोग्रामिंग भाषा)]] के लिए कोई आधिकारिक स्टाइल गाइड नहीं है, आर-गुरु हैडली विकम की टिडीवर्स स्टाइल गाइड अधिकांश उपयोगकर्ताओं के लिए | जबकि [[आर (प्रोग्रामिंग भाषा)|आर (प्रोग्रामिंग लैंग्वेज)]] के लिए कोई आधिकारिक स्टाइल गाइड नहीं है, आर-गुरु हैडली विकम की टिडीवर्स स्टाइल गाइड अधिकांश उपयोगकर्ताओं के लिए स्टैण्डर्ड निर्धारित करती है।<ref name=tidyverse>[https://style.tidyverse.org/ Style Guide for RCode ]</ref> यह मार्गदर्शिका फ़ाइल नामों में विशेष वर्णों से बचने और वेरिएबल और फ़ंक्शन नामों के लिए केवल संख्याओं, अक्षरों और अंडरस्कोर फिट_मॉडल.आर का उपयोग करने की अनुशंसा करती है। | ||
===राकू=== | ===राकू=== | ||
[[राकू (प्रोग्रामिंग भाषा)]] कमोबेश पर्ल जैसी ही | [[राकू (प्रोग्रामिंग भाषा)|राकू (प्रोग्रामिंग लैंग्वेज)]] कमोबेश पर्ल जैसी ही कन्वेंशन का पालन करती है, अतिरिक्त इसके कि यह इन्फ़िक्स हाइफ़न की अनुमति देती है <code>-</code> या धर्मोपदेश <code>'</code> (या एकल उद्धरण) पहचानकर्ता के अन्दर (किन्तु पंक्ति में दो नहीं), किन्तु इसके पश्चात् वर्णमाला वर्ण हो। राकू प्रोग्रामर अधिकांशतः अपने पहचानकर्ताओं में कबाब केस का उपयोग करते हैं; उदाहरण के लिए,<code>fish-food</code> और <code>don't-do-that</code> वैध पहचानकर्ता हैं.<ref>{{Cite web | title = General rules of Perl 6 syntax | url = https://docs.perl6.org/language/syntax#Identifiers }}</ref> | ||
===रस्ट === | |||
<ref>{{Cite web | title = General rules of Perl 6 syntax | url = https://docs.perl6.org/language/syntax#Identifiers }}</ref> | रस्ट (प्रोग्रामिंग लैंग्वेज) अनुशंसा करता है <code>UpperCamelCase</code> एक प्रकार के उपनाम और संरचना, विशेषता, एनम और एनम प्रकार के नामों के लिए, <code>SCREAMING_SNAKE_CASE</code> कांस्टेंट या स्थैतिक के लिए और <code>snake_case</code> वेरिएबल, फ़ंक्शन और संरचना सदस्य नामों के लिए उपयोग किया जाता है।<ref>{{Cite web|url=https://doc.rust-lang.org/1.0.0/style/style/naming/README.html|title=नामकरण की परंपरा|website=doc.rust-lang.org|language=en|access-date=2018-02-04}}</ref> | ||
=== | |||
रस्ट (प्रोग्रामिंग | |||
===स्विफ्ट=== | ===स्विफ्ट=== | ||
[[स्विफ्ट (प्रोग्रामिंग भाषा)]] ने प्रत्येक व्यक्तिगत रिलीज के साथ अपनी | [[स्विफ्ट (प्रोग्रामिंग भाषा)|स्विफ्ट (प्रोग्रामिंग लैंग्वेज)]] ने प्रत्येक व्यक्तिगत रिलीज के साथ अपनी नेमिंग कन्वेंशन को परिवर्तित कर दिया है। चूंकि, स्विफ्ट 3.0 के साथ एक प्रमुख अपडेट ने वेरिएबल्स और फ़ंक्शन घोषणाओं में <code>lowerCamelCase</code> के लिए नेमिंग परंपराओं को स्थिर कर दिया था। स्थिरांक को सामान्यतः एनम प्रकार या स्थिर मापदंडों द्वारा परिभाषित किया जाता है जिन्हें इस तरह भी लिखा जाता है। क्लास और अन्य ऑब्जेक्ट प्रकार की घोषणाएँ <code>UpperCamelCase</code> हैं। | ||
स्विफ्ट 3.0 के अनुसार सभी तृतीय पक्ष एपीआई में एपीआई नेमिंग और घोषणा कन्वेंशन को मानकीकृत करने के प्रयास में लैंग्वेज के लिए स्पष्ट नेमिंग दिशानिर्देश बनाए गए हैं।<ref>{{Cite web | title = स्विफ्ट.ओआरजी एपीआई डिज़ाइन दिशानिर्देश| url = http://swift.org/documentation/api-design-guidelines/#conventions }}</ref> | |||
==यह भी देखें== | ==यह भी देखें== | ||
* | *श्रेणी:[[नामकरण परंपरा|नेमिंग]] कन्वेंशन | ||
*[[चेकस्टाइल]] | *[[चेकस्टाइल]] | ||
*[[कोडिंग कन्वेंशन]] | *[[कोडिंग कन्वेंशन]] | ||
*[[स्थैतिक कोड विश्लेषण के लिए उपकरणों की सूची]] | *[[स्थैतिक कोड विश्लेषण के लिए उपकरणों की सूची]] | ||
*[[ नाम स्थान ]] | *[[ नाम स्थान |नेमस्पेस]] | ||
* | *नेमिंग कन्वेंशन | ||
*[[सिगिल (कंप्यूटर प्रोग्रामिंग)]] | *[[सिगिल (कंप्यूटर प्रोग्रामिंग)]] | ||
*सिंटेक्स (प्रोग्रामिंग | *सिंटेक्स (प्रोग्रामिंग लैंग्वेज) | ||
==संदर्भ== | ==संदर्भ== | ||
{{Reflist}} | {{Reflist}} | ||
==बाहरी संबंध== | ==बाहरी संबंध== | ||
Line 331: | Line 296: | ||
[[Category: Machine Translated Page]] | [[Category: Machine Translated Page]] | ||
[[Category:Created On 15/08/2023]] | [[Category:Created On 15/08/2023]] | ||
[[Category:Vigyan Ready]] |
Latest revision as of 07:25, 16 October 2023
कंप्यूटर प्रोग्रामिंग में, नेमिंग कन्वेंशन आइडेंटिफायर (कंप्यूटर लैंग्वेज) के लिए उपयोग किए जाने वाले वर्ण अनुक्रम को चुनने के लिए नियमों का सेट है जो सोर्स कोड और सॉफ़्टवेयर डॉक्यूमेंटेशन में वेरिएबल (कंप्यूटर विज्ञान), डेटा टाइप, फंक्शन और अन्य इकाइयो को दर्शाता है।
नेमिंग कन्वेंशन का उपयोग करने के कारणों (प्रोग्रामर को किसी भी वर्ण अनुक्रम को चुनने की अनुमति देने के विपरीत) में निम्नलिखित सम्मिलित हैं:
- सोर्स कोड को पढ़ने और समझने के लिए आवश्यक प्रयास को कम करने के लिए;[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
रूप में दर्शाया जाएगा।
हाइफ़न का उपयोग कोबोल (1959), फोर्थ (प्रोग्रामिंग लैंग्वेज) (1970), और लिस्प (प्रोग्रामिंग लैंग्वेज) (1958) लिखने वाले लगभग सभी प्रोग्रामर द्वारा किया जाता है; यह यूनिक्स में कमांड और पैकेज के लिए भी सामान्य है, और इसका उपयोग कैस्केडिंग स्टाइल शीट्स में किया जाता है।[5] इस कन्वेंशन का कोई स्टैण्डर्ड नाम नहीं है, चूंकि इसे लिस्प-केस या कोबोल-केस (पास्कल केस की तुलना करें), कबाब-केस, ब्रोचेट-केस या अन्य वेरिएंट के रूप में संदर्भित किया जा सकता है।[6][7][8][9] इनमें से, कबाब-केस, कम से कम 2012 का है,[10] तब से कुछ मुद्रा प्राप्त की है।[11][12]
इसके विपरीत, फोरट्रान/एएलजीओएल कन्वेंशन की लैंग्वेज, विशेष रूप से सी (प्रोग्रामिंग लैंग्वेज) और पास्कल (प्रोग्रामिंग लैंग्वेज) वर्गों की लैंग्वेज, सब्ट्रेक्शन इन्फिक्स नोटेशन ऑपरेटर के लिए हाइफ़न का उपयोग करती थीं, और इसके चारों ओर रिक्त स्थान की आवश्यकता नहीं चाहती थीं (जैसा फ्री -फ़ॉर्म लैंग्वेज), पहचानकर्ताओं में इसके उपयोग को रोकना है।
विकल्प अंडरस्कोर का उपयोग करना है; यह सी वर्ग (पायथन सहित) में सामान्य है, छोटे अक्षरों के साथ, उदाहरण के सी प्रोग्रामिंग लैंग्वेज (1978) में पाया जाता है, और इसे स्नैक केस या स्नेल केस के रूप में जाना जाता है। अपरकेस के साथ अंडरस्कोर, जैसे कि अपर_केस में, सामान्यतः सी प्रीप्रोसेसर मैक्रोज़ के लिए उपयोग किया जाता है, इसलिए इसे मैक्रो_केस के रूप में जाना जाता है, और यूनिक्स में पर्यावरण वरिएबल के लिए, जैसे बैश (यूनिक्स शेल) में बैश_वर्जन के लिए उपयोग किया जाता है। कभी-कभी इसे सामान्यतः स्क्रिमिंग_स्नेक_केस (वैकल्पिक रूप से स्क्रिमिंग_स्नेक_केस) कहा जाता है।
लेटर केस-सेपरेटेड वार्ड
अन्य दृष्टिकोण मध्यस्थ पूंजीकरण का उपयोग करके शब्द सीमाओं को संकेत करना है, जिसे कैमल केस, पास्कलकेस और विभिन्न अन्य नाम कहा जाता है, इस प्रकार two words
जैसा क्रमशः twoWords
याTwoWords
रेंडरिंग किया जाता है. यह कन्वेंशन सामान्यतः पास्कल (प्रोग्रामिंग लैंग्वेज), जावा (प्रोग्रामिंग लैंग्वेज), सी शार्प (प्रोग्रामिंग लैंग्वेज) या सी#, और मूल दृश्य में उपयोग किया जाता है। पहचानकर्ताओं में आरंभिक शब्दों का उपचार (उदाहरण के लिए एक्सएमएल और एचटीटीपी में)। XMLHttpRequest
) भिन्न होता है। कुछ लोग निर्देश देते हैं कि उन्हें छोटा किया जाए (उदा. XmlHttpRequest
) टाइपिंग, पठनीयता और सेगमेंटेशन को सरल बनाने के लिए, जबकि स्पष्टता के लिए उन्हें बड़े अक्षरों में छोड़ देते हैं (उदाहरण के लिएXMLHTTPRequest
)।
एकाधिक-शब्द पहचानकर्ता प्रारूपों के उदाहरण
फ़ॉर्मेटिंग | नाम(s) |
---|---|
twowords
|
फ़्लैटकेस[13][14] |
TWOWORDS
|
अपरकेस[13] |
twoWords
|
(लोअर) कैमलकेस, ड्रोमेडरीकेस |
TwoWords
|
पास्कलकेस, अपरकैमलकेस, स्टडीलीकेस[15] |
two_words
|
स्नेक_केस, स्नेल_केस, पोथोले_केस |
TWO_WORDS
|
आल_कैप्स, स्क्रिमिंग_स्नेक_केस,[16] मैक्रो_केस, कांस्टेंट_केस |
two_Words
|
कैमल_स्नेक_केस |
Two_Words
|
पास्कल_स्नेक_केस, टाइटल_केस |
two-words
|
कबाब-केस, डैश-केस, लिस्प-केस, स्पाइनल-केस |
TWO-WORDS
|
ट्रेन-केस, कोबोल-केस, स्क्रिमिग-कबाब-केस |
Two-Words
|
ट्रेन-केस,[13] एचटीटीपी-हैडर-केस[17] |
मेटाडेटा और हाइब्रिड कन्वेंशन
कुछ नेमिंग कन्वेंशन उन नियमों या आवश्यकताओं का प्रतिनिधित्व करती हैं जो आवश्यकताओं से परे हैं किसी विशिष्ट प्रोजेक्ट या समस्या डोमेन का, और इसके अतिरिक्त बड़ा प्रतिबिंबित करता है सॉफ़्टवेयर आर्किटेक्चर, अंतर्निहित प्रोग्रामिंग लैंग्वेज या अन्य प्रकार की क्रॉस-प्रोजेक्ट पद्धति द्वारा परिभाषित सिद्धांतों का व्यापक सेट है।
हंगेरियन नोटेशन
शायद सबसे प्रसिद्ध हंगेरियन नोटेशन है, जो अपने नाम में वरिएबल के उद्देश्य (एप्स हंगेरियन) या डेटा टाइप (सिस्टम हंगेरियन) को एन्कोड करता है।[18] उदाहरण के लिए, वेरिएबल szName के लिए उपसर्ग sz संकेत करता है कि वेरिएबल नल-टर्मिनेटेड स्ट्रिंग है।
पोजिशनल नोटेशन
बहुत कम (आठ अक्षर और उससे कम) के लिए उपयोग की जाने वाली स्टाइल LCCIIL01 हो सकती है:, जहां एल.सी अनुप्रयोग (लेटर ऑफ क्रेडिट) होगा, सी कोबोल के लिए, IIL विशेष प्रक्रिया सबसेट के लिए, और 01 अनुक्रम संख्या होती है।
इस प्रकार का कन्वेंशन अभी भी जेसीएल लैंग्वेज पर निर्भर मेनफ्रेम में सक्रिय उपयोग में है और इसे 8.3 (पीरियड सेपरेटर के साथ अधिकतम आठ अक्षर और उसके पश्चात् तीन अक्षर फ़ाइल प्रकार) एमएस-डॉस स्टाइल में भी देखा जाता है।
कम्पोजिट वर्ड स्कीम (लैंग्वेज ओएफ)
आईबीएम की ओएफ लैंग्वेज को आईएमएस (सूचना प्रबंधन प्रणाली) मैनुअल में प्रलेखित किया गया था।
इसमें प्राइम-मोडिफायर-क्लास वर्ड योजना का विवरण दिया गया, जिसमें ग्राहक खाता संख्या को संकेत करने के लिए कस्टडी-एक्ट-नं जैसे नाम सम्मिलित थे।
प्राइम वर्ड किसी सिस्टम में रुचि रखने वाली प्रमुख संस्थाओं को संकेत करने के लिए थे।
अतिरिक्त परिशोधन, योग्यता और पठनीयता के लिए संशोधक शब्दों का प्रयोग किया गया था।
क्लास वर्ड आदर्श रूप से किसी विशेष एप्लिकेशन के लिए प्रासंगिक डेटा प्रकारों की बहुत छोटी सूची होगी। सामान्य वर्ग के शब्द हो सकते हैं: NO (संख्या), ID (पहचानकर्ता), TXT (पाठ), AMT (राशि), QTY (मात्रा), FL (ध्वज), CD (कोड), W (कार्य) इत्यादि। व्यवहार में, उपलब्ध क्लास वर्ड दो दर्जन से कम शब्दों की सूची होगी।
क्लास वर्ड, सामान्यतः दाईं ओर (प्रत्यय) स्थित होते हैं, हंगेरियन नोटेशन उपसर्गों के समान ही उद्देश्य पूरा करते हैं।
क्लास शब्दों का उद्देश्य, स्थिरता के अतिरिक्त, प्रोग्रामर को किसी विशेष डेटा फ़ील्ड के डेटा प्रकार को निर्दिष्ट करना था। बूलियन (केवल दो मान) फ़ील्ड की स्वीकृति से पहले, FL (ध्वज) केवल दो संभावित मानों वाले फ़ील्ड को संकेत करता है।
लैंग्वेज-स्पेसिफिक कन्वेंशन
एकमा स्क्रिप्ट
एडोब के कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास एक्शनस्क्रिप्ट के लिए नेमिंग स्टैण्डर्ड का सुझाव देते हैं जो अधिकतर ईसीएमएस्क्रिप्ट के अनुरूप होते हैं।[citation needed] पहचानकर्ताओं की स्टाइल जावा (प्रोग्रामिंग लैंग्वेज) के समान है।
एडीए
एडा (प्रोग्रामिंग लैंग्वेज) में, पहचानकर्ताओं की एकमात्र अनुशंसित स्टाइल Mixed_Case_With_Underscores
है .[19]
एपीएल
एपीएल (प्रोग्रामिंग लैंग्वेज) बोलियों में, डेल्टा (Δ) का उपयोग शब्दों के बीच किया जाता है, जैसे PERFΔSQUARE (पुराने एपीएल संस्करणों में पारंपरिक रूप से कोई लोअरकेस उपस्थित नहीं था)। यदि नाम में अंडरस्कोर वाले अक्षरों का उपयोग किया गया है, तो इसके स्थान पर डेल्टा अंडरबार (⍙) का उपयोग किया जाता है।
सी और सी++
सी (प्रोग्रामिंग लैंग्वेज) और सी++ में, कीवर्ड (कंप्यूटर प्रोग्रामिंग) और स्टैण्डर्ड लाइब्रेरी आइडेंटिफायर अधिकतर लोअरकेस होते हैं। सी स्टैण्डर्ड लाइब्रेरी में, संक्षिप्त नाम सबसे सामान्य हैं (उदाहरण के लिए) isalnum
किसी फ़ंक्शन के परीक्षण के लिए कि क्या कोई वर्ण अल्फ़ान्यूमेरिक है), जबकि सी++ स्टैण्डर्ड लाइब्रेरी अधिकांशतः शब्द विभाजक के रूप में अंडरस्कोर का उपयोग करती है (उदा. out_of_range
). सी प्रीप्रोसेसर#मैक्रो परिभाषा और विस्तार का प्रतिनिधित्व करने वाले पहचानकर्ता, कन्वेंशन के अनुसार, केवल अपरकेस अक्षरों और अंडरस्कोर का उपयोग करके लिखे गए हैं (यह विभिन्न प्रोग्रामिंग लैंग्वेज में कांस्टेंट के लिए आल-अपर-केस पहचानकर्ताओं का उपयोग करने की कन्वेंशन से संबंधित है)। डबल अंडरस्कोर वाले या अंडरस्कोर और बड़े अक्षर से प्रारंभ होने वाले नाम कार्यान्वयन ( कंपाइलर , स्टैण्डर्ड लाइब्रेरी) के लिए आरक्षित हैं और उनका उपयोग नहीं किया जाना चाहिए (उदाहरण के लिए__reserved
या _Reserved
) .[20][21] यह सुपरफिसिअल्ली स्ट्रॉपिंग (वाक्यविन्यास) के समान है, किन्तु शब्दार्थ पृथक-पृथक हैं: अंडरस्कोर वर्णों को उद्धृत करने के अतिरिक्त पहचानकर्ता के मूल्य का भाग हैं (जैसा कि स्ट्रॉपिंग है): __foo का मान __foo है (जो आरक्षित है), foo नहीं (किन्तु एक पृथक नामस्थान में)
सी#
सी शार्प (प्रोग्रामिंग लैंग्वेज) या सी# नेमिंग कन्वेंशन सामान्यतः सभी .नेट लैंग्वेज के लिए माइक्रोसॉफ्ट द्वारा प्रकाशित दिशानिर्देशों का पालन करती हैं [22] (नीचे .नेट अनुभाग देखें), किन्तु सी# कंपाइलर द्वारा कोई कन्वेंशन प्रयुक्त नहीं की जाती है।
माइक्रोसॉफ्ट दिशानिर्देश केवल इसके विशेष उपयोग PascalCase
और कैमलकेस
की अनुशंसा करते हैं ,इसके पश्चात् वाले का उपयोग केवल विधि पैरामीटर नामों और विधि-स्थानीय वरिएबल नामों (विधि-स्थानीय सहित const
मान) के लिए किया जाता है । पास्कलकेस में विशेष अपवाद दो-अक्षर वाले संक्षिप्ताक्षरों के लिए बनाया गया है जो पहचानकर्ता प्रारंभ करते हैं; इन स्थितियों में, दोनों अक्षर बड़े अक्षरों में लिखे गए हैं (उदाहरण के लिए, IOStream
); बड़े संक्षिप्त शब्दों (उदाहरण के लिए, XmlStream
) के स्थिति में ऐसा नहीं है. दिशानिर्देश interface
अनुशंसा करते हैं कि जो नाम PascalCase
दिया गया है जिसके बड़े अक्षर से पहले I
, जो जैसा कि IEnumerable
में है।
फ़ील्ड नेमिंग के लिए माइक्रोसॉफ्ट दिशानिर्देश static
, public
, और protected
के लिए विशिष्ट हैं; वे क्षेत्र जो static
नहीं हैं और जिनमें अन्य पहुंच स्तर हैं (जैसे internal
और private
) स्पष्ट रूप से दिशानिर्देशों में शामिल नहीं हैं।[23] सबसे आम अभ्यास सभी फ़ील्ड के नामों के लिए PascalCase
का उपयोग करना है, अतिरिक्त उन फ़ील्ड्स के जो private
हैं (और न ही const
और न static
), जिन्हें ऐसे नाम दिए गए हैं जो एकल अंडरस्कोर से पहले कैमलकेस
का उपयोग करते हैं; उदाहरण के लिए, _totalCount है
किसी भी पहचानकर्ता नाम के पहले अर्थ में कोई परिवर्तन किए बिना वाणिज्यिक-एट प्रतीक (@) लगाया जा सकता है। अर्थात्, factor
और @factor
दोनों एक ही वस्तु को संदर्भित करते हैं। परंपरा के अनुसार, इस उपसर्ग का उपयोग केवल उन स्थितियों में किया जाता है जब पहचानकर्ता अन्यथा एक आरक्षित कीवर्ड (जैसे कि for
और while
) होगा, जिसे उपसर्ग के बिना पहचानकर्ता के रूप में उपयोग नहीं किया जा सकता है, या एक प्रासंगिक कीवर्ड (जैसे कि from
और where
) ), जिन स्थितियों में उपसर्ग की सख्ती से आवश्यकता नहीं है (कम से कम इसकी घोषणा पर नहीं; उदाहरण के लिए, चूंकि घोषणा dynamic dynamic;
; वैध है, इसे सामान्यतः dynamic dynamic;
के रूप में देखा जाएगा; पाठक को तुरंत इंगित करने के लिए कि पश्चात् वाला एक परिवर्तनीय नाम है)।
डार्ट/फ्लाटर
फ़्लटर_(सॉफ़्टवेयर) में प्रयुक्त डार्ट_(प्रोग्रामिंग_लैंग्वेज) लैंग्वेज में, कन्वेंशन जावा के समान हैं, अतिरिक्त इसके कि कांस्टेंट लोअरकैमलकेस में लिखे गए हैं। डार्ट वाक्यात्मक नियम प्रयुक्त करता है कि गैर-स्थानीय आइडेंटिफायर अंडरस्कोर से प्रारंभ होते हैं (_
) को निजी माना जाता है (चूंकि लैंग्वेज में सार्वजनिक या निजी पहुंच के लिए स्पष्ट कीवर्ड नहीं हैं)। इसके अतिरिक्त, सोर्स फ़ाइल नाम जावा के प्रति सोर्स फ़ाइल के सार्वजनिक वर्ग का पालन नहीं करते हैं, नाम नियम से मेल खाना चाहिए, इसके अतिरिक्त फ़ाइल नाम के लिए स्नैक_केस का उपयोग करें।[24]
गो
गो में, मल्टीवर्ड नाम लिखने के लिए अंडरस्कोर के अतिरिक्त MixedCaps
या mixedCaps
का उपयोग करने की परंपरा है। संरचनाओं या कार्यों का संदर्भ देते समय, पहला अक्षर बाहरी पैकेजों के लिए दृश्यता निर्दिष्ट करता है। पहला अक्षर अपरकेस बनाने से कोड का वह भाग निर्यात हो जाता है, जबकि लोअरकेस इसे केवल वर्तमान सीमा में ही प्रयोग करने योग्य बनाता है।[25]
जावा
जावा (प्रोग्रामिंग लैंग्वेज) में, पहचानकर्ताओं के लिए नेमिंग कन्वेंशन विभिन्न जावा कम्युनिटी जैसे सन माइक्रोसिस्टम्स, द्वारा स्थापित और सुझाई गई हैं।[26] नेटस्केप,[27] एम्बीसॉफ्ट,[28] आदि। सन माइक्रोसिस्टम्स द्वारा निर्धारित नेमिंग कन्वेंशन का प्रारूप नीचे सूचीबद्ध है,
जहां कैमलकेस में नाम बिना रिक्त स्थान के जुड़े हुए विभिन्न शब्दों से बना है, प्रत्येक शब्द का - पहले शब्द को छोड़कर - बड़े अक्षरों में प्रारंभिक अक्षर है - उदाहरण के लिए कैमलकेस है।
पहचानकर्ता का प्रकार | नेमिंग के नियम | उदाहरण |
---|---|---|
क्लासेस | कक्षा के नाम अपरकैमलकेस में संज्ञा होने चाहिए, प्रत्येक शब्द का पहला अक्षर बड़े अक्षरों में होना चाहिए। पूरे शब्दों का उपयोग करें - संक्षिप्ताक्षरों से बचें (जब तक कि संक्षिप्ताक्षर बड़े रूप की तुलना में अधिक व्यापक रूप से उपयोग नहीं किया जाता है, जैसे कि यूआरएल या एचटीएमएल)। |
|
विधियाँ | विधियाँ लोअरकेमलकेस में क्रिया होनी चाहिए या एक बहु-शब्द नाम जो लोअरकेस में एक क्रिया से प्रारंभ होता है; यह अपरकेस में पहले अक्षर लोअरकेस और इसके पश्चात के शब्दों के पहले अक्षर के साथ है। |
|
वैरिएबल | स्थानीय वैरिएबल, इंस्टेंस वैरिएबल और क्लास वैरिएबल भी लोअरकैमलकेस में लिखे गए हैं। परिवर्तनीय नाम अंडरस्कोर (_) या डॉलर चिह्न ($) वर्णों से प्रारंभ नहीं होने चाहिए, तथापि दोनों की अनुमति हो। यह अन्य कोडिंग कन्वेंशन के विपरीत है जो बताती है कि सभी इंस्टेंस वेरिएबल्स को उपसर्ग करने के लिए अंडरस्कोर का उपयोग किया जाना चाहिए।
परिवर्तनीय नाम छोटे किन्तु अर्थपूर्ण होने चाहिए। एक परिवर्तनीय नाम का चुनाव स्मरणीय होना चाहिए - अर्थात, आकस्मिक पर्यवेक्षक को इसके उपयोग के उद्देश्य को इंगित करने के लिए डिज़ाइन किया गया है। अस्थायी "थ्रोअवे" वेरिएबल को छोड़कर एक-वर्ण वाले वेरिएबल नामों से बचना चाहिए। अस्थायी वैरिएबल के सामान्य नाम पूर्णांकों के लिए i, j, k, m, और n हैं; वर्णों के लिए c, d, और e। |
|
स्थिरांक | स्थिरांक को अंडरस्कोर द्वारा पृथक किए गए अपरकेस वर्णों में लिखा जाना चाहिए। यदि उपयुक्त हो तो निरंतर नामों में अंक भी हो सकते हैं, लेकिन पहले अक्षर के रूप में नहीं। |
|
जावा कंपाइलर इन नियमों को प्रयुक्त नहीं करते हैं, किन्तु उनका पालन करने में विफल रहने से भ्रम और गलत कोड हो सकता है। उदाहरण के लिए, widget.expand()
और Widget.expand()
महत्वपूर्ण रूप से भिन्न व्यवहार दर्शाते हैं: widget.expand()
विधि के आह्वान का तात्पर्य है expand()
नामक उदाहरण में widget
, जबकि Widget.expand()
स्थैतिक विधि के आह्वान का तात्पर्य expand()
कक्षा में Widget
है.
एक व्यापक रूप से उपयोग की जाने वाली जावा कोडिंग स्टाइल यह निर्देश देती है कि UpperCamelCase
का उपयोग कक्षाओं के लिए किया जाना चाहिए और lowerCamelCase
का उपयोग उदाहरणों और विधियों के लिए किया जाना चाहिए। [26] इस उपयोग को पहचानते हुए, कुछ आईडीई, जैसे एक्लिप्स, कैमलकेस पर आधारित शॉर्टकट प्रयुक्त करते हैं। उदाहरण के लिए, एक्लिप्स की सामग्री सहायता सुविधा में, कैमलकेस शब्द के केवल बड़े अक्षरों को टाइप करने से कोई भी मिलान वर्ग या विधि का नाम सुझाया जाएगा (उदाहरण के लिए, "एनपीई" टाइप करना और सामग्री सहायता को सक्रिय करना NullPointerException
का सुझाव दे सकता है)।
तीन या अधिक अक्षरों के प्रथमाक्षर अपरकेस के अतिरिक्त कैमलकेस हैं (जैसे, parseDbmXmlFromIPAddress
के अतिरिक्त parseDBMXMLFromIPAddress
). कोई व्यक्ति दो या अधिक अक्षरों पर भी सीमा निर्धारित कर सकता है (उदा. parseDbmXmlFromIpAddress
).
जावास्क्रिप्ट
अंतर्निहित जावास्क्रिप्ट लाइब्रेरीज़ जावा के समान नेमिंग कन्वेंशन का उपयोग करती हैं। डेटा प्रकार और कंस्ट्रक्टर फ़ंक्शन अपर कैमल केस (RegExp
, TypeError
, XMLHttpRequest
, DOMObject
) का उपयोग करते हैं और विधियां लोअर कैमल केस (getElementById
, getElementsByTagNameNS
, createCDATASection
) का उपयोग करते हैं। सुसंगत रहने के लिए अधिकांश जावास्क्रिप्ट डेवलपर इन कन्वेंशन का पालन करते हैं। [29] यह भी देखें: डगलस क्रॉकफोर्ड के कन्वेंशन
लिस्प
अधिकांश लिस्प (प्रोग्रामिंग लैंग्वेज) बोलियों में सामान्य अभ्यास पहचानकर्ताओं में शब्दों को पृथक करने के लिए डैश का उपयोग करना है, जैसा कि with-open-file
और make-hash-table
. डायनामिक वरिएबल नाम परंपरागत रूप से तारांकन *map-walls*
. के साथ प्रारंभ और समाप्त होते हैं: स्थिरांकों के नाम धन चिह्न +map-size+
से चिह्नित होते हैं: .[30][31]
.नेट
माइक्रोसॉफ्ट .नेट अधिकांश पहचानकर्ताओं के लिए UpperCamelCase
अनुशंसा करता है , जिसे पास्कलकेस के रूप में भी जाना जाता है। (lowerCamelCase
पैरामीटर (कंप्यूटर विज्ञान) और वरिएबल (प्रोग्रामिंग) ) के लिए अनुशंसित है और यह .नेट लैंग्वेज के लिए साझा कन्वेंशन है।[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]
पीएचपी
पीएचपी पक्ष समर्थन पीएसआर-1 (पीएचपी स्टैण्डर्ड पक्ष समर्थन 1) और पीएसआर-12 में सम्मिलित हैं।[39] पीएसआर-1 के अनुसार, क्लास के नाम पास्कलकेस में होने चाहिए, क्लास कांस्टेंट मैक्रो_केस में होने चाहिए, और फ़ंक्शन और विधि के नाम कैमलकेस में होने चाहिए।[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]
यह भी देखें
- श्रेणी:नेमिंग कन्वेंशन
- चेकस्टाइल
- कोडिंग कन्वेंशन
- स्थैतिक कोड विश्लेषण के लिए उपकरणों की सूची
- नेमस्पेस
- नेमिंग कन्वेंशन
- सिगिल (कंप्यूटर प्रोग्रामिंग)
- सिंटेक्स (प्रोग्रामिंग लैंग्वेज)
संदर्भ
- ↑ Derek M. Jones "Operand names influence operator precedence decisions" An experiment investigating the effect of variable names on operator precedence selection
- ↑ Raymond, Eric S. (1 October 2004). "धार्मिक मुद्दे". The Jargon File (version 4.4.8 ed.). Retrieved 7 November 2011.
- ↑ 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.
- ↑ Naming a Package
- ↑ "सीएसएस संदर्भ". Mozilla Developer Network. Retrieved 2016-06-18.
- ↑ "StackOverflow – What's the name for snake_case with dashes?".
- ↑ "Programmers – If this is camelCase what-is-this?".
- ↑ "Camel_SNAKE-kebab". GitHub. September 2019.
- ↑ UnderscoreVersusCapitalAndLowerCaseVariableNaming
- ↑ jwfearn (5 September 2012). "Revisions to jwfearn's answer to What's the name for dash-separated case?".
- ↑ Living Clojure (2015), by Carin Meier, p. 91
- ↑ lodash: kebabCase
- ↑ 13.0 13.1 13.2 "naming - What are the different kinds of cases?". Stack Overflow. Retrieved 2020-08-16.
- ↑ "A brief list of programming naming conventions". deanpugh.com (in British English). 2018-03-20. Retrieved 2020-08-16.
- ↑ "PSR-1: Basic Coding Standard - PHP-FIG". www.php-fig.org (in English). Retrieved 2020-09-04.
- ↑ "Naming conventions". doc.rust-lang.org. Retrieved 2023-05-02.
- ↑ "camel-snake-kebab". camel-snake-kebab (in English). Retrieved 2020-08-16.
- ↑ "गलत कोड बनाना गलत दिखना". Joel on Software. 11 May 2005.
- ↑ "3.2.1 Names - Chapter 3 - Ada 95 QUALITY AND STYLE Guide".
- ↑ "ISO/IEC 9899:1999 Programming languages – C". ISO.
- ↑ "ISO/IEC 14882:2011 Information technology – Programming languages – C++". ISO.
- ↑ "नामकरण दिशानिर्देश". Microsoft. 15 September 2021.
- ↑ "प्रकार सदस्यों के नाम". Microsoft. 15 September 2021.
- ↑ "Effective Dart - the Dart Style Guide".
- ↑ "Effective Go - the Go Programming Language".
- ↑ 26.0 26.1 "Code Conventions for the Java Programming Language", Section 9: "Naming Conventions"
- ↑ "NETSCAPE'S SOFTWARE CODING STANDARDS GUIDE FOR JAVA",Collab Software Coding Standards Guide for Java Archived 3 March 2009 at the Wayback Machine
- ↑ "AmbySoft Inc. Coding Standards for Java v17.01d"
- ↑ Morelli, Brandon (17 November 2017). "5 JavaScript Style Guides – Including AirBnB, GitHub, & Google". codeburst.io. Retrieved 17 August 2018.
- ↑ "Variables".
- ↑ Naming conventions on CLiki
- ↑ Microsoft .NET Framework Capitalization Styles
- ↑ .NET Framework Developer's Guide – General Naming Conventions
- ↑ [Framework Design Guidelines, Krzysztof Cwalina, Brad Abrams Page 62]
- ↑ Modula-2 Name Convention
- ↑ Foreign API Identifiers in Modula-2 Name Convention
- ↑ "पर्ल स्टाइल गाइड".
- ↑ "perlmodlib – constructing new Perl modules and finding existing ones".
- ↑ "PHP मानक सिफ़ारिशें".
- ↑ "PSR-1: Basic Coding Standard - PHP-FIG".
- ↑ Style Guide for Python Code PEP8
- ↑ Style Guide for RCode
- ↑ "General rules of Perl 6 syntax".
- ↑ "नामकरण की परंपरा". doc.rust-lang.org (in English). Retrieved 2018-02-04.
- ↑ "स्विफ्ट.ओआरजी एपीआई डिज़ाइन दिशानिर्देश".
बाहरी संबंध
- coding-guidelines.com has a pdf that uses linguistics and psychology to attempt a cost/benefit analysis of identifier naming issues