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

Revision as of 09:33, 6 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) में पाया जाता है, और इसे स्नैक केस या स्नेल केस के रूप में जाना जाता है। अपरकेस के साथ अंडरस्कोर, जैसे कि UPPER_CASE में, सामान्यतः सी प्रीप्रोसेसर मैक्रोज़ के लिए उपयोग किया जाता है, इसलिए इसे MACRO_CASE के रूप में जाना जाता है, और यूनिक्स में पर्यावरण वरिएबल के लिए, जैसे बैश (यूनिक्स शेल) में BASH_VERSION के लिए उपयोग किया जाता है। कभी-कभी इसे सामान्यतः SCREAMING_SNAKE_CASE (वैकल्पिक रूप से SCREAMING_SNAIL_CASE) कहा जाता है।

लेटर केस-सेपरेटेड वार्ड

अन्य दृष्टिकोण मध्यस्थ पूंजीकरण का उपयोग करके शब्द सीमाओं को इंगित करना है, जिसे कैमल केस, पास्कलकेस और विभिन्न अन्य नाम कहा जाता है, इस प्रकार 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, जहां LC अनुप्रयोग (लेटर ऑफ क्रेडिट) होगा, C कोबोल के लिए, 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 अपरकेस.	`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 अपरकेस 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]

यह भी देखें

श्रेणी:नामकरण कन्वेंशन
चेकस्टाइल
कोडिंग कन्वेंशन
स्थैतिक कोड विश्लेषण के लिए उपकरणों की सूची
नाम स्थान
नेमिंग कन्वेंशन
सिगिल (कंप्यूटर प्रोग्रामिंग)
सिंटेक्स (प्रोग्रामिंग लैंग्वेज)

संदर्भ

↑ 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

[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 2016-06-18.

[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] wfearn (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] sh: kebabCase

[:0-13] 13.0 ^13.1 ^13.2 "naming - What are the different kinds of cases?". Stack Overflow. Retrieved 2020-08-16.

[14] "A brief list of programming naming conventions". deanpugh.com (in British English). 2018-03-20. Retrieved 2020-08-16.

[15] "PSR-1: Basic Coding Standard - PHP-FIG". www.php-fig.org (in English). Retrieved 2020-09-04.

[16] "Naming conventions". doc.rust-lang.org. Retrieved 2023-05-02.

[:1-17] "camel-snake-kebab". camel-snake-kebab (in English). Retrieved 2020-08-16.

[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".

[SunJavaCodeConv-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".

[PSR-39] "PHP मानक सिफ़ारिशें".

[40] "PSR-1: Basic Coding Standard - PHP-FIG".

[pep8-41] Style Guide for Python Code PEP8

[tidyverse-42] Style Guide for RCode

[43] "General rules of Perl 6 syntax".

[44] "नामकरण की परंपरा". doc.rust-lang.org (in English). Retrieved 2018-02-04.

[45] "स्विफ्ट.ओआरजी एपीआई डिज़ाइन दिशानिर्देश".

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

@@ Line 1: / Line 1: @@
 {{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>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> कई कंपनियों ने अपने स्वयं के सम्मेलनों का सेट भी स्थापित किया है।
+नेमिंग कन्वेंशन का चुनाव अत्यंत विवादास्पद विषय हो सकता है, जिसमें प्रत्येक पक्षकार अपने को सर्वोत्तम और दूसरों को निम्नतर मानते हैं। बोलचाल की लैंग्वेज में इसे [[हठधर्मिता]] की स्थिति कहा जाता है।<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 33: / Line 33: @@
   a = b * c;
 </syntaxhighlight>
-क्या [[सिंटैक्स (प्रोग्रामिंग भाषाएँ)]] सही है, इसका उद्देश्य स्पष्ट नहीं है। इसकी तुलना इससे करें:
+क्या [[सिंटैक्स (प्रोग्रामिंग भाषाएँ)|सिंटैक्स (प्रोग्रामिंग लैंग्वेज)]] सही है, इसका उद्देश्य स्पष्ट नहीं है। इसकी तुलना इससे करें:
 <syntaxhighlight lang="C">
   weekly_pay = hours_worked * hourly_pay_rate;
 </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>{{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>
-==सामान्य तत्व==
+==कॉमन एलिमेंट==
-नामकरण परंपरा के सटीक नियम उस संदर्भ पर निर्भर करते हैं जिसमें उनका उपयोग किया जाता है। फिर भी, ऐसे कई सामान्य तत्व हैं जो आज आम उपयोग में आने वाली सभी नामकरण परंपराओं को नहीं तो सबसे अधिक प्रभावित करते हैं।
+नेमिंग कन्वेंशन के स्पष्ट नियम उस संदर्भ पर निर्भर करते हैं जिसमें उनका उपयोग किया जाता है। फिर भी, ऐसे विभिन्न कॉमन एलिमेंट हैं जो आज सामान्य उपयोग में आने वाली सभी नेमिंग कन्वेंशन को नहीं तो सबसे अधिक प्रभावित करते हैं।
 ===पहचानकर्ताओं की लंबाई===
-सभी नामकरण परंपराओं के मौलिक तत्व पहचानकर्ता की लंबाई (यानी, पहचानकर्ता में अनुमत व्यक्तिगत वर्णों की सीमित संख्या) से संबंधित नियम हैं। कुछ नियम निश्चित संख्यात्मक सीमा निर्धारित करते हैं, जबकि अन्य कम सटीक अनुमान या दिशानिर्देश निर्दिष्ट करते हैं।
+सभी नेमिंग कन्वेंशन के मौलिक एलिमेंट पहचानकर्ता की लंबाई (अतिरिक्त, पहचानकर्ता में अनुमत व्यक्तिगत वर्णों की सीमित संख्या) से संबंधित नियम हैं। कुछ नियम निश्चित संख्यात्मक सीमा निर्धारित करते हैं, जबकि अन्य कम स्पष्ट अनुमान या दिशानिर्देश निर्दिष्ट करते हैं।
-पहचानकर्ता लंबाई नियमों का व्यवहार में नियमित रूप से विरोध किया जाता है, और अकादमिक रूप से बहुत बहस का विषय होता है।
+पहचानकर्ता लंबाई नियमों का व्यवहार में नियमित रूप से विरोध किया जाता है, और शैक्षिक रूप से बहुत विचार का विषय होता है।
 कुछ विचार:
-* छोटे पहचानकर्ताओं को अधिक समीचीन के रूप में प्राथमिकता दी जा सकती है, क्योंकि उन्हें टाइप करना आसान होता है (हालांकि कई आईडीई और टेक्स्ट-संपादक टेक्स्ट-पूर्णता प्रदान करते हैं, जो इसे कम करता है)
+* छोटे पहचानकर्ताओं को अधिक उपयुक्त के रूप में प्राथमिकता दी जा सकती है, क्योंकि उन्हें टाइप करना सरल होता है (चूंकि विभिन्न आईडीई और टेक्स्ट-एडिटर टेक्स्ट-पूर्णता प्रदान करते हैं, जो इसे कम करता है)
-* अत्यंत संक्षिप्त पहचानकर्ता (जैसे कि 'i' या 'j') को स्वचालित खोज और प्रतिस्थापन टूल का उपयोग करके विशिष्ट रूप से अलग करना बहुत मुश्किल है (हालांकि यह [[नियमित अभिव्यक्ति]]-आधारित टूल के लिए कोई समस्या नहीं है)
+* अत्यंत संक्षिप्त पहचानकर्ता (जैसे कि 'i' या 'j') को स्वचालित खोज और प्रतिस्थापन टूल का उपयोग करके विशिष्ट रूप से पृथक करना बहुत कठिन है (चूंकि यह [[नियमित अभिव्यक्ति|नियमित]] रेगेक्स-बेस्ड टूल के लिए कोई समस्या नहीं है)
-* लंबे पहचानकर्ताओं को प्राथमिकता दी जा सकती है क्योंकि छोटे पहचानकर्ता पर्याप्त जानकारी को एन्कोड नहीं कर सकते हैं या बहुत गूढ़ दिखाई देते हैं
+* बड़े पहचानकर्ताओं को प्राथमिकता दी जा सकती है क्योंकि छोटे पहचानकर्ता पर्याप्त जानकारी को एन्कोड नहीं कर सकते हैं या बहुत अलौकिक दिखाई देते हैं
-* दृश्य अव्यवस्था के कारण लंबे पहचानकर्ताओं को नापसंद किया जा सकता है
+* दृश्य अव्यवस्था के कारण बड़े पहचानकर्ताओं को नापसंद किया जा सकता है
-यह खुला शोध मुद्दा है कि क्या कुछ प्रोग्रामर छोटे पहचानकर्ताओं को पसंद करते हैं क्योंकि उन्हें लंबे पहचानकर्ताओं की तुलना में टाइप करना या सोचना आसान होता है, या क्योंकि कई स्थितियों में लंबा पहचानकर्ता केवल दृश्यमान कोड को अव्यवस्थित करता है और कोई अतिरिक्त लाभ नहीं देता है।
+यह विवृत शोध विषय है कि क्या कुछ प्रोग्रामर छोटे पहचानकर्ताओं को पसंद करते हैं क्योंकि उन्हें बड़े पहचानकर्ताओं की तुलना में टाइप करना या सोचना सरल होता है, या क्योंकि विभिन्न स्थितियों में बड़े पहचानकर्ता केवल दृश्यमान कोड को अव्यवस्थित करता है और कोई अतिरिक्त लाभ नहीं देता है।
-प्रोग्रामिंग में संक्षिप्तता का कुछ हद तक कारण यह हो सकता है:
+प्रोग्रामिंग में संक्षिप्तता का कुछ सीमा तक कारण यह हो सकता है:
-* प्रारंभिक [[लिंकर (कंप्यूटिंग)]] जिसमें मेमोरी को बचाने के लिए वेरिएबल नामों को 6 अक्षरों तक सीमित करना आवश्यक था। बाद की प्रगति ने मानवीय समझ के लिए लंबे परिवर्तनशील नामों का उपयोग करने की अनुमति दी, लेकिन जहां केवल पहले कुछ अक्षर ही महत्वपूर्ण थे। [[ बुनियादी |बुनियादी]] के कुछ संस्करणों जैसे टीआरएस-80 लेवल 2 बेसिक में, लंबे नामों की अनुमति थी, लेकिन केवल पहले दो अक्षर ही महत्वपूर्ण थे। इस सुविधा ने गलत व्यवहार की अनुमति दी जिसे डीबग करना मुश्किल हो सकता है, उदाहरण के लिए जब VALUE और VAT जैसे नामों का उपयोग किया गया था और अलग होने का इरादा था।
+* प्रारंभिक [[लिंकर (कंप्यूटिंग)]] जिसमें मेमोरी को बचाने के लिए वेरिएबल नामों को 6 अक्षरों तक सीमित करना आवश्यक था। इसके पश्चात की प्रगति ने मानवीय समझ के लिए बड़े परिवर्तनशील नामों का उपयोग करने की अनुमति दी थी, किन्तु जहां केवल पहले कुछ अक्षर ही महत्वपूर्ण थे। [[ बुनियादी |मूलभूत]] के कुछ संस्करणों जैसे टीआरएस-80 लेवल 2 बेसिक में, बड़े नामों की अनुमति थी, किन्तु केवल पहले दो अक्षर ही महत्वपूर्ण थे। इस सुविधा ने गलत व्यवहार की अनुमति दी जिसे डीबग करना कठिन हो सकता है, उदाहरण के लिए जब VALUE और VAT जैसे नामों का उपयोग किया गया था और पृथक होने का आशय था।
-* प्रारंभिक [[स्रोत कोड संपादक]]ों में [[स्वत: पूर्ण]]ता का अभाव है
+* प्रारंभिक [[स्रोत कोड संपादक|सोर्स कोड एडिटर]] में [[स्वत: पूर्ण]]ता का अभाव है
-* प्रारंभिक कम-रिज़ॉल्यूशन मॉनिटर सीमित लाइन लंबाई के साथ (उदाहरण के लिए केवल 80 अक्षर)
+* प्रारंभिक लो-रिज़ॉल्यूशन मॉनिटर सीमित लाइन लंबाई के साथ (उदाहरण के लिए केवल 80 अक्षर)
-* कंप्यूटर विज्ञान का अधिकांश भाग गणित से उत्पन्न हुआ है, जहां चर नाम परंपरागत रूप से केवल अक्षर होते हैं
+* कंप्यूटर विज्ञान का अधिकांश भाग गणित से उत्पन्न हुआ है, जहां वरिएबल नाम परंपरागत रूप से केवल अक्षर होते हैं
-===अक्षर केस और अंक===
+===लेटर केस और अंक===
-कुछ नामकरण परंपराएं यह सीमित करती हैं कि अक्षर अपरकेस या लोअरकेस में दिखाई दे सकते हैं या नहीं। अन्य
+कुछ नेमिंग कन्वेंशन यह सीमित करती हैं कि लेटर अपरकेस या लोअरकेस में दिखाई दे सकते हैं या नहीं। अन्य कन्वेंशन लेटर स्थिति को प्रतिबंधित नहीं करतीं है, किन्तु अच्छी तरह से परिभाषित व्याख्या आधारित करती हैं लेटर स्थिति पर कुछ नेमिंग कन्वेंशन निर्दिष्ट करती हैं कि वर्णमाला, संख्यात्मक या अल्फ़ान्यूमेरिक वर्णों का उपयोग किया जा सकता है, और यदि हां, तो किस क्रम में आदि।
-परंपराएं अक्षर मामले को प्रतिबंधित नहीं करतीं, बल्कि अच्छी तरह से परिभाषित व्याख्या आधारित करती हैं
-पत्र मामले पर. कुछ नामकरण परंपराएँ निर्दिष्ट करती हैं कि वर्णमाला, संख्यात्मक या अल्फ़ान्यूमेरिक
-वर्णों का उपयोग किया जा सकता है, और यदि हां, तो किस क्रम में।
 ===एकाधिक-[[शब्द]] पहचानकर्ता===
-सामान्य अनुशंसा सार्थक पहचानकर्ताओं का उपयोग करना है। शब्द अनेक शब्दों जितना सार्थक या विशिष्ट नहीं हो सकता। नतीजतन, कुछ नामकरण परंपराएं से अधिक शब्द वाले यौगिक पहचानकर्ताओं के उपचार के लिए नियम निर्दिष्ट करती हैं।
+सामान्य अनुशंसा सार्थक पहचानकर्ताओं का उपयोग करना है। शब्द अनेक शब्दों जितना सार्थक या विशिष्ट नहीं हो सकता है। परिणाम स्वरुप, कुछ नेमिंग कन्वेंशन से अधिक शब्द वाले यौगिक पहचानकर्ताओं के उपचार के लिए नियम निर्दिष्ट करती हैं।
-चूंकि अधिकांश [[प्रोग्रामिंग भाषा]]एं पहचानकर्ताओं में व्हाइटस्पेस (कंप्यूटर विज्ञान) की अनुमति नहीं देती हैं, इसलिए प्रत्येक शब्द को परिसीमित करने की विधि की आवश्यकता होती है (बाद के पाठकों के लिए यह व्याख्या करना आसान हो जाता है कि कौन से अक्षर किस शब्द से संबंधित हैं)। ऐतिहासिक रूप से कुछ प्रारंभिक भाषाओं, विशेष रूप से [[फोरट्रान]] (1955) और एएलजीओएल (1958) ने, संदर्भ के अनुसार पहचानकर्ताओं के अंत का निर्धारण करते हुए, पहचानकर्ताओं के भीतर रिक्त स्थान की अनुमति दी। टोकनाइजेशन (शब्दावली विश्लेषण) की कठिनाई के कारण बाद की भाषाओं में इसे छोड़ दिया गया। केवल शब्दों को जोड़कर नाम लिखना संभव है, और इसका उपयोग कभी-कभी किया जाता है, जैसे कि <code>mypackage</code> जावा पैकेज नामों के लिए,<ref>[https://docs.oracle.com/javase/tutorial/java/package/namingpkgs.html Naming a Package]</ref> हालाँकि लंबे समय तक सुपाठ्यता प्रभावित होती है, इसलिए आमतौर पर किसी न किसी रूप में पृथक्करण का उपयोग किया जाता है।
+चूंकि अधिकांश [[प्रोग्रामिंग भाषा|प्रोग्रामिंग]] लैंग्वेज पहचानकर्ताओं में व्हाइटस्पेस (कंप्यूटर विज्ञान) की अनुमति नहीं देती हैं, इसलिए प्रत्येक शब्द को परिसीमित करने की विधि की आवश्यकता होती है (पश्चात् के पाठकों के लिए यह व्याख्या करना सरल हो जाता है कि कौन से अक्षर किस शब्द से संबंधित हैं)। ऐतिहासिक रूप से कुछ प्रारंभिक लैंग्वेज, विशेष रूप से [[फोरट्रान]] (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>.
+दृष्टिकोण [[अक्षरांकीय]] वर्ण के साथ पृथक-पृथक शब्दों को परिसीमित करना है। इस उद्देश्य के लिए सामान्यतः उपयोग किए जाने वाले दो लेटर [[हैफ़ेन]] (-) और [[ बल देना |अंडरस्कोर]] (_) हैं; उदाहरण के लिए, दो शब्दों वाला नाम<code>two words</code>के <code>two-words</code>या<code>two_words</code>रूप में दर्शाया जाएगा।
-हाइफ़न का उपयोग [[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> इस कन्वेंशन का कोई मानक नाम नहीं है, हालाँकि इसे लिस्प-केस या COBOL-CASE (पास्कल केस की तुलना करें), कबाब-केस, ब्रोचेट-केस या अन्य वेरिएंट के रूप में संदर्भित किया जा सकता है।<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>
+हाइफ़न का उपयोग [[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) में पाया जाता है, और इसे [[ साँप का मामला |साँप का मामला]] या स्नेल केस के रूप में जाना जाता है। अपरकेस के साथ अंडरस्कोर, जैसे कि UPPER_CASE में, आमतौर पर [[सी प्रीप्रोसेसर]] मैक्रोज़ के लिए उपयोग किया जाता है, इसलिए इसे MACRO_CASE के रूप में जाना जाता है, और यूनिक्स में पर्यावरण चर के लिए, जैसे [[बैश (यूनिक्स शेल)]] में BASH_VERSION के लिए उपयोग किया जाता है। कभी-कभी इसे मज़ाकिया तौर पर SCREAMING_SNAKE_CASE (वैकल्पिक रूप से SCREAMING_SNAIL_CASE) कहा जाता है।
+इसके विपरीत, फोरट्रान/एएलजीओएल कन्वेंशन की लैंग्वेज, विशेष रूप से [[सी (प्रोग्रामिंग भाषा)|सी (प्रोग्रामिंग लैंग्वेज)]] और [[पास्कल (प्रोग्रामिंग भाषा)|पास्कल (प्रोग्रामिंग लैंग्वेज)]] वर्गों की लैंग्वेज, [[घटाव|सब्ट्रेक्शन]] [[ इन्फिक्स संकेतन |इन्फिक्स नोटेशन]] ऑपरेटर के लिए हाइफ़न का उपयोग करती थीं, और इसके चारों ओर रिक्त स्थान की आवश्यकता नहीं चाहती थीं (जैसा फ्री -फ़ॉर्म लैंग्वेज), पहचानकर्ताओं में इसके उपयोग को रोकना है।
-====अक्षर केस-पृथक शब्द====
+विकल्प अंडरस्कोर का उपयोग करना है; यह सी वर्ग (पायथन सहित) में सामान्य है, छोटे अक्षरों के साथ, उदाहरण के [[सी प्रोग्रामिंग भाषा|सी प्रोग्रामिंग]] लैंग्वेज (1978) में पाया जाता है, और इसे [[ साँप का मामला |स्नैक केस]] या स्नेल केस के रूप में जाना जाता है। अपरकेस के साथ अंडरस्कोर, जैसे कि UPPER_CASE में, सामान्यतः [[सी प्रीप्रोसेसर]] मैक्रोज़ के लिए उपयोग किया जाता है, इसलिए इसे MACRO_CASE के रूप में जाना जाता है, और यूनिक्स में पर्यावरण वरिएबल के लिए, जैसे [[बैश (यूनिक्स शेल)]] में BASH_VERSION के लिए उपयोग किया जाता है। कभी-कभी इसे सामान्यतः SCREAMING_SNAKE_CASE (वैकल्पिक रूप से SCREAMING_SNAIL_CASE) कहा जाता है।
-{{See also|Letter case#Special case styles}}
-अन्य दृष्टिकोण मध्यस्थ पूंजीकरण का उपयोग करके शब्द सीमाओं को इंगित करना है, जिसे [[टेढ़े - मेढ़े लिखावट वाले बड़े संयुक्त शब्द]], पास्कलकेस और कई अन्य नाम कहा जाता है, इस प्रकार क्रमशः प्रतिपादन किया जाता है<code>two words</code>जैसा<code>twoWords</code>या<code>TwoWords</code>. यह कन्वेंशन आमतौर पर पास्कल (प्रोग्रामिंग भाषा), [[जावा (प्रोग्रामिंग भाषा)]], सी शार्प (प्रोग्रामिंग भाषा)|सी#, और [[ मूल दृश्य |मूल दृश्य]] में उपयोग किया जाता है। पहचानकर्ताओं में आरंभिक शब्दों का उपचार (उदाहरण के लिए [[XML]] और [[HTTP]] में)। <code>[[XMLHttpRequest]]</code>) भिन्न होता है। कुछ लोग निर्देश देते हैं कि उन्हें छोटा किया जाए (उदा. <code>XmlHttpRequest</code>) टाइपिंग, पठनीयता और [[पाठ विभाजन]] को आसान बनाने के लिए, जबकि अन्य उन्हें बड़े अक्षरों में छोड़ देते हैं (उदाहरण के लिए) <code>XMLHTTPRequest</code>) सटीकता के लिए।
-====बहु-शब्द पहचानकर्ता प्रारूपों के उदाहरण====
+====लेटर केस-सेपरेटेड वार्ड====
+{{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"
-|+Multiple-word identifier formats
+|+एकाधिक-शब्द पहचानकर्ता प्रारूप
-!Formatting
+!फ़ॉर्मेटिंग
-!Name(s)
+!नाम(s)
 |-
 |<code>twowords</code>
-|flatcase<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>
+|फ़्लैटकेस<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>
-|UPPERCASE<ref name=":0" />
+|अपरकेस<ref name=":0" />
 |-
 |<code>twoWords</code>
-|(lower) [[Camel case|camelCase]], dromedaryCase
+|(लोअर) कैमलकेस, ड्रोमेडरीकेस
 |-
 |<code>TwoWords</code>
-|PascalCase, UpperCamelCase, StudlyCase<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>
+|पास्कलकेस, अपरकैमलकेस, स्टडीलीकेस<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>
-|[[snake_case]], snail_case, pothole_case
+|स्नेक_केस, स्नेल_केस, पोथोले_केस
 |-
 |<code>TWO_WORDS</code>
-|ALL_CAPS, [[SCREAMING_SNAKE_CASE]],<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> MACRO_CASE, CONSTANT_CASE
+|आल_कैप्स, स्क्रिमिंग_स्नेक_केस,<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>
-|camel_Snake_Case
+|कैमल_स्नेक_केस
 |-
 |<code>Two_Words</code>
-|Pascal_Snake_Case, Title_Case
+|पास्कल_स्नेक_केस, टाइटल_केस
 |-
 |<code>two-words</code>
-|[[Kebab case|kebab-case]], dash-case, lisp-case, spinal-case
+|[[Kebab case|कबाब-केस]], डैश-केस, लिस्प-केस, स्पाइनल-केस
 |-
 |<code>TWO-WORDS</code>
-|TRAIN-CASE, COBOL-CASE, SCREAMING-KEBAB-CASE
+|ट्रेन-केस, कोबोल-केस, स्क्रिमिग-कबाब-केस
 |-
 |<code>Two-Words</code>
-|Train-Case,<ref name=":0" /> HTTP-Header-Case<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 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 इंगित करता है कि वेरिएबल शून्य-समाप्त स्ट्रिंग है।
+शायद सबसे प्रसिद्ध हंगेरियन नोटेशन है, जो अपने नाम में वरिएबल के उद्देश्य (एप्स हंगेरियन) या [[ डेटा प्रकार |डेटा प्रकार]] (सिस्टम हंगेरियन) को एन्कोड करता है।<ref>{{Cite news | url=http://www.joelonsoftware.com/articles/Wrong.html |title = गलत कोड बनाना गलत दिखना|newspaper = Joel on Software|date = 11 May 2005}}</ref> उदाहरण के लिए, वेरिएबल szName के लिए उपसर्ग sz इंगित करता है कि वेरिएबल शून्य-समाप्त स्ट्रिंग है।
-===स्थिति संकेतन===
+===स्थिति नोटेशन===
-बहुत कम (आठ अक्षर और उससे कम) के लिए उपयोग की जाने वाली शैली हो सकती है: LCCIIL01, जहां LC अनुप्रयोग (लेटर ऑफ क्रेडिट) होगा, C COBOL के लिए, IIL विशेष प्रक्रिया उपसमुच्चय के लिए, और 01 अनुक्रम संख्या होगी।
+बहुत कम (आठ अक्षर और उससे कम) के लिए उपयोग की जाने वाली स्टाइल हो सकती है: LCCIIL01, जहां LC अनुप्रयोग (लेटर ऑफ क्रेडिट) होगा, C कोबोल के लिए, IIL विशेष प्रक्रिया उपसमुच्चय के लिए, और 01 अनुक्रम संख्या होगी।
-इस प्रकार का सम्मेलन अभी भी [[ कार्य नियंत्रण भाषा |कार्य नियंत्रण भाषा]] पर निर्भर मेनफ्रेम में सक्रिय उपयोग में है और इसे 8.3 (पीरियड सेपरेटर के साथ अधिकतम आठ अक्षर और उसके बाद तीन अक्षर फ़ाइल प्रकार) एमएस-डॉस शैली में भी देखा जाता है।
+इस प्रकार का सम्मेलन अभी भी [[ कार्य नियंत्रण भाषा |कार्य नियंत्रण]] लैंग्वेज पर निर्भर मेनफ्रेम में सक्रिय उपयोग में है और इसे 8.3 (पीरियड सेपरेटर के साथ अधिकतम आठ अक्षर और उसके पश्चात् तीन अक्षर फ़ाइल प्रकार) एमएस-डॉस स्टाइल में भी देखा जाता है।
-===समग्र शब्द योजना (भाषा की)===
+===समग्र शब्द योजना (लैंग्वेज की)===
-IBM की OF भाषा को IMS ([[सूचना प्रबंधन प्रणाली]]) मैनुअल में प्रलेखित किया गया था।
+IBM की OF लैंग्वेज को IMS ([[सूचना प्रबंधन प्रणाली]]) मैनुअल में प्रलेखित किया गया था।
-इसमें प्राइम-मोडिफायर-क्लास शब्द योजना का विवरण दिया गया, जिसमें ग्राहक खाता संख्या को इंगित करने के लिए CUST-ACT-NO जैसे नाम शामिल थे।
+इसमें प्राइम-मोडिफायर-क्लास शब्द योजना का विवरण दिया गया, जिसमें ग्राहक खाता संख्या को इंगित करने के लिए CUST-ACT-NO जैसे नाम सम्मिलित थे।
 PRIME शब्द किसी सिस्टम में रुचि रखने वाली प्रमुख संस्थाओं को इंगित करने के लिए थे।
@@ Line 160: / Line 157: @@
 क्लास शब्द आदर्श रूप से किसी विशेष एप्लिकेशन के लिए प्रासंगिक डेटा प्रकारों की बहुत छोटी सूची होगी। सामान्य वर्ग के शब्द हो सकते हैं: NO (संख्या), ID (पहचानकर्ता), TXT (पाठ), AMT (राशि), QTY (मात्रा), FL (ध्वज), CD (कोड), W (कार्य) इत्यादि। व्यवहार में, उपलब्ध क्लास शब्द दो दर्जन से कम शब्दों की सूची होगी।
-क्लास शब्द, आमतौर पर दाईं ओर (प्रत्यय) स्थित होते हैं, हंगेरियन नोटेशन उपसर्गों के समान ही उद्देश्य पूरा करते हैं।
+क्लास शब्द, सामान्यतः दाईं ओर (प्रत्यय) स्थित होते हैं, हंगेरियन नोटेशन उपसर्गों के समान ही उद्देश्य पूरा करते हैं।
-क्लास शब्दों का उद्देश्य, स्थिरता के अलावा, प्रोग्रामर को किसी विशेष डेटा फ़ील्ड के डेटा प्रकार को निर्दिष्ट करना था। बूलियन (केवल दो मान) फ़ील्ड की स्वीकृति से पहले, FL (ध्वज) केवल दो संभावित मानों वाले फ़ील्ड को इंगित करेगा।
+क्लास शब्दों का उद्देश्य, स्थिरता के अतिरिक्त, प्रोग्रामर को किसी विशेष डेटा फ़ील्ड के डेटा प्रकार को निर्दिष्ट करना था। बूलियन (केवल दो मान) फ़ील्ड की स्वीकृति से पहले, FL (ध्वज) केवल दो संभावित मानों वाले फ़ील्ड को इंगित करेगा।
-==भाषा-विशिष्ट परंपराएँ==
+==लैंग्वेज-विशिष्ट कन्वेंशन==
 ===[[एकमा स्क्रिप्ट]]===
-एडोब के कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास [[ ActionScript |ActionScript]] के लिए नामकरण मानकों का सुझाव देते हैं जो ज्यादातर ईसीएमएस्क्रिप्ट के अनुरूप होते हैं।{{Citation needed|date=November 2011}} पहचानकर्ताओं की शैली जावा (प्रोग्रामिंग भाषा) के समान है।
+एडोब के कोडिंग कन्वेंशन और सर्वोत्तम अभ्यास [[ 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>
+[[एडा (प्रोग्रामिंग भाषा)|एडा (प्रोग्रामिंग लैंग्वेज)]] में, पहचानकर्ताओं की एकमात्र अनुशंसित स्टाइल है <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 (पुराने एपीएल संस्करणों में पारंपरिक रूप से कोई लोअरकेस मौजूद नहीं था)। यदि नाम में अंडरस्कोर वाले अक्षरों का उपयोग किया गया है, तो इसके स्थान पर डेल्टा अंडरबार (⍙) का उपयोग किया जाएगा।
 ===सी और [[सी++]]===
-C (प्रोग्रामिंग भाषा) और C++ में, [[कीवर्ड (कंप्यूटर प्रोग्रामिंग)]] और मानक लाइब्रेरी पहचानकर्ता अधिकतर लोअरकेस होते हैं। सी मानक लाइब्रेरी में, संक्षिप्त नाम सबसे आम हैं (उदाहरण के लिए) <code>isalnum</code> किसी फ़ंक्शन के परीक्षण के लिए कि क्या कोई वर्ण अल्फ़ान्यूमेरिक है), जबकि C++ मानक लाइब्रेरी अक्सर शब्द विभाजक के रूप में अंडरस्कोर का उपयोग करती है (उदा. <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> यह सतही तौर पर स्ट्रॉपिंग (वाक्यविन्यास) के समान है, लेकिन शब्दार्थ अलग-अलग हैं: अंडरस्कोर वर्णों को उद्धृत करने के बजाय पहचानकर्ता के मूल्य का हिस्सा हैं (जैसा कि स्ट्रॉपिंग है): का मूल्य <code>__foo</code> है <code>__foo</code> (जो आरक्षित है), नहीं <code>foo</code> (लेकिन अलग नामस्थान में)।
+C (प्रोग्रामिंग लैंग्वेज) और C++ में, [[कीवर्ड (कंप्यूटर प्रोग्रामिंग)]] और स्टैण्डर्ड लाइब्रेरी आइडेंटिफायर अधिकतर लोअरकेस होते हैं। सी स्टैण्डर्ड लाइब्रेरी में, संक्षिप्त नाम सबसे आम हैं (उदाहरण के लिए) <code>isalnum</code> किसी फ़ंक्शन के परीक्षण के लिए कि क्या कोई वर्ण अल्फ़ान्यूमेरिक है), जबकि C++ स्टैण्डर्ड लाइब्रेरी अधिकांशतः शब्द विभाजक के रूप में अंडरस्कोर का उपयोग करती है (उदा. <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> यह सतही तौर पर स्ट्रॉपिंग (वाक्यविन्यास) के समान है, किन्तु शब्दार्थ पृथक-पृथक हैं: अंडरस्कोर वर्णों को उद्धृत करने के अतिरिक्त पहचानकर्ता के मूल्य का हिस्सा हैं (जैसा कि स्ट्रॉपिंग है): का मूल्य <code>__foo</code> है <code>__foo</code> (जो आरक्षित है), नहीं <code>foo</code> (किन्तु पृथक नामस्थान में)।
 ===सी#===
-सी शार्प (प्रोग्रामिंग भाषा)|सी# नामकरण परंपराएं आम तौर पर सभी .NET भाषाओं के लिए माइक्रोसॉफ्ट द्वारा प्रकाशित दिशानिर्देशों का पालन करती हैं<ref>{{Cite web | title = नामकरण दिशानिर्देश| date = 15 September 2021 | publisher = Microsoft | url = https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions}}</ref> (नीचे .NET अनुभाग देखें), लेकिन C# कंपाइलर द्वारा कोई परंपरा लागू नहीं की जाती है।
+सी शार्प (प्रोग्रामिंग लैंग्वेज)|सी# नेमिंग कन्वेंशन आम तौर पर सभी .NET लैंग्वेज के लिए माइक्रोसॉफ्ट द्वारा प्रकाशित दिशानिर्देशों का पालन करती हैं<ref>{{Cite web | title = नामकरण दिशानिर्देश| date = 15 September 2021 | publisher = Microsoft | url = https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions}}</ref> (नीचे .NET अनुभाग देखें), किन्तु C# कंपाइलर द्वारा कोई कन्वेंशन प्रयुक्त नहीं की जाती है।
-Microsoft दिशानिर्देश केवल इसके विशेष उपयोग की अनुशंसा करते हैं <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>.
+Microsoft दिशानिर्देश केवल इसके विशेष उपयोग की अनुशंसा करते हैं <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>.
-फ़ील्ड के नामकरण के लिए Microsoft दिशानिर्देश विशिष्ट हैं <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>camelCase</code> एकल अंडरस्कोर से पहले; उदाहरण के लिए, <code>_totalCount</code>.
+फ़ील्ड के नेमिंग के लिए Microsoft दिशानिर्देश विशिष्ट हैं <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>camelCase</code> एकल अंडरस्कोर से पहले; उदाहरण के लिए, <code>_totalCount</code>.
-किसी भी पहचानकर्ता नाम के पहले वाणिज्यिक-एट प्रतीक लगाया जा सकता है (<code>@</code>), अर्थ में कोई बदलाव किए बिना। यानी दोनों <code>factor</code> और <code>@factor</code> ही वस्तु का संदर्भ लें. परंपरा के अनुसार, इस उपसर्ग का उपयोग केवल उन मामलों में किया जाता है जब पहचानकर्ता अन्यथा आरक्षित कीवर्ड होगा (जैसे <code>for</code> और <code>while</code>), जिसका उपयोग उपसर्ग, या प्रासंगिक कीवर्ड (जैसे कि) के बिना पहचानकर्ता के रूप में नहीं किया जा सकता है <code>from</code> और <code>where</code>), किन मामलों में उपसर्ग की सख्ती से आवश्यकता नहीं है (कम से कम इसकी घोषणा पर नहीं; उदाहरण के लिए, हालांकि घोषणा <code>dynamic&nbsp;dynamic;</code> वैध है, इसे आमतौर पर इस रूप में देखा जाएगा <code>dynamic&nbsp;@dynamic;</code> पाठक को तुरंत इंगित करने के लिए कि बाद वाला परिवर्तनीय नाम है)।
+किसी भी पहचानकर्ता नाम के पहले वाणिज्यिक-एट प्रतीक लगाया जा सकता है (<code>@</code>), अर्थ में कोई बदलाव किए बिना। अतिरिक्त दोनों <code>factor</code> और <code>@factor</code> ही वस्तु का संदर्भ लें. कन्वेंशन के अनुसार, इस उपसर्ग का उपयोग केवल उन स्थितियों में किया जाता है जब पहचानकर्ता अन्यथा आरक्षित कीवर्ड होगा (जैसे <code>for</code> और <code>while</code>), जिसका उपयोग उपसर्ग, या प्रासंगिक कीवर्ड (जैसे कि) के बिना पहचानकर्ता के रूप में नहीं किया जा सकता है <code>from</code> और <code>where</code>), किन स्थितियों में उपसर्ग की सख्ती से आवश्यकता नहीं है (कम से कम इसकी घोषणा पर नहीं; उदाहरण के लिए, चूंकि घोषणा <code>dynamic&nbsp;dynamic;</code> वैध है, इसे सामान्यतः इस रूप में देखा जाएगा <code>dynamic&nbsp;@dynamic;</code> पाठक को तुरंत इंगित करने के लिए कि पश्चात् वाला परिवर्तनीय नाम है)।
 ===डार्ट/फड़फड़ाना===
-फ़्लटर_(सॉफ़्टवेयर) में प्रयुक्त डार्ट_(प्रोग्रामिंग_भाषा) भाषा में, कन्वेंशन जावा के समान हैं,
+फ़्लटर_(सॉफ़्टवेयर) में प्रयुक्त डार्ट_(प्रोग्रामिंग_भाषा) लैंग्वेज में, कन्वेंशन जावा के समान हैं,
-सिवाय इसके कि स्थिरांक लोअरकैमलकेस में लिखे गए हैं।
+सिवाय इसके कि कांस्टेंट लोअरकैमलकेस में लिखे गए हैं।
-डार्ट वाक्यात्मक नियम लागू करता है कि गैर-स्थानीय पहचानकर्ता अंडरस्कोर से शुरू होते हैं (<code>_</code>) को निजी माना जाता है
+डार्ट वाक्यात्मक नियम प्रयुक्त करता है कि गैर-स्थानीय आइडेंटिफायर अंडरस्कोर से शुरू होते हैं (<code>_</code>) को निजी माना जाता है
-(चूंकि भाषा में सार्वजनिक या निजी पहुंच के लिए स्पष्ट कीवर्ड नहीं हैं)।
+(चूंकि लैंग्वेज में सार्वजनिक या निजी पहुंच के लिए स्पष्ट कीवर्ड नहीं हैं)।
-इसके अतिरिक्त, स्रोत फ़ाइल नाम जावा के प्रति स्रोत फ़ाइल के सार्वजनिक वर्ग का पालन नहीं करते हैं, नाम नियम से मेल खाना चाहिए,
+इसके अतिरिक्त, सोर्स फ़ाइल नाम जावा के प्रति सोर्स फ़ाइल के सार्वजनिक वर्ग का पालन नहीं करते हैं, नाम नियम से मेल खाना चाहिए,
-इसके बजाय फ़ाइल नाम के लिए साँप_केस का उपयोग करें।<ref>{{Cite web | url=https://dart.dev/guides/language/effective-dart/style | title=Effective Dart - the Dart Style Guide}}</ref>
+इसके अतिरिक्त फ़ाइल नाम के लिए साँप_केस का उपयोग करें।<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>
+गो (प्रोग्रामिंग लैंग्वेज) में, कन्वेंशन का उपयोग करना है <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> आदि। सन माइक्रोसिस्टम्स द्वारा निर्धारित नामकरण परंपराओं का नमूना नीचे सूचीबद्ध है,
+जावा (प्रोग्रामिंग लैंग्वेज) में, पहचानकर्ताओं के लिए नेमिंग कन्वेंशन विभिन्न जावा समुदायों जैसे सन माइक्रोसिस्टम्स, द्वारा स्थापित और सुझाई गई हैं।<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> आदि। सन माइक्रोसिस्टम्स द्वारा निर्धारित नेमिंग कन्वेंशन का नमूना नीचे सूचीबद्ध है,
-जहां CamelCase में नाम बिना रिक्त स्थान के जुड़े हुए कई शब्दों से बना है, प्रत्येक शब्द का - पहले शब्द को छोड़कर - बड़े अक्षरों में प्रारंभिक अक्षर - उदाहरण के लिए CamelCase।
+जहां CamelCase में नाम बिना रिक्त स्थान के जुड़े हुए विभिन्न शब्दों से बना है, प्रत्येक शब्द का - पहले शब्द को छोड़कर - बड़े अक्षरों में प्रारंभिक अक्षर - उदाहरण के लिए CamelCase।
 {| class="wikitable" border="1"
 |-
@@ Line 218: / Line 215: @@
 |-
 | Methods
-| Methods should be verbs in <code>lower[[CamelCase]]</code> 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.
+| Methods should be verbs in <code>lower[[CamelCase]]</code> 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 अपरकेस.
 |
 * <code>run();</code>
@@ Line 234: / Line 231: @@
 |-
 |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.
+|Constants should be written in अपरकेस characters separated by underscores. Constant names may also contain digits if appropriate, but not as the first character.
 |
 * {{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>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>[[CamelCase|UpperCamelCase]]</code> [[कक्षा (कंप्यूटर विज्ञान)]] और के लिए उपयोग किया जाए <code>[[CamelCase|lowerCamelCase]]</code> उदाहरण के लिए (कंप्यूटर विज्ञान) और [[विधि (कंप्यूटर विज्ञान)]] का उपयोग किया जाना चाहिए।<ref name="SunJavaCodeConv" />इस उपयोग को पहचानते हुए, कुछ एकीकृत विकास वातावरण, जैसे कि [[ग्रहण (आईडीई)]]आईडीई), कैमलकेस पर आधारित शॉर्टकट प्रयुक्त करते हैं। उदाहरण के लिए, एक्लिप्स की [[सामग्री सहायता]] सुविधा में, कैमलकेस शब्द के केवल बड़े अक्षरों को टाइप करने से कोई भी मिलान वर्ग या विधि का नाम सुझाया जाएगा (उदाहरण के लिए, एनपीई टाइप करना और सामग्री सहायता को सक्रिय करना सुझाव दे सकता है) <code>NullPointerException</code>).
-तीन या अधिक अक्षरों के प्रथमाक्षर अपरकेस के बजाय CamelCase हैं (जैसे, <code>parseDbmXmlFromIPAddress</code> के बजाय <code>parseDBMXMLFromIPAddress</code>). कोई व्यक्ति दो या अधिक अक्षरों पर भी सीमा निर्धारित कर सकता है (उदा. <code>parseDbmXmlFromIpAddress</code>).
+तीन या अधिक अक्षरों के प्रथमाक्षर अपरकेस के अतिरिक्त CamelCase हैं (जैसे, <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>
+अंतर्निहित जावास्क्रिप्ट लाइब्रेरीज़ जावा के समान नेमिंग कन्वेंशन का उपयोग करती हैं। डेटा प्रकार और कंस्ट्रक्टर फ़ंक्शन अपर कैमल केस का उपयोग करते हैं (<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 डगलस क्रॉकफोर्ड के सम्मेलन]
 ===लिस्प===
-अधिकांश लिस्प (प्रोग्रामिंग भाषा) बोलियों में सामान्य अभ्यास पहचानकर्ताओं में शब्दों को अलग करने के लिए डैश का उपयोग करना है, जैसा कि <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>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>
 ===.NET===
-Microsoft .NET अनुशंसा करता है <code>[[CamelCase|UpperCamelCase]]</code>, जिसे अधिकांश पहचानकर्ताओं के लिए पास्कलकेस के रूप में भी जाना जाता है। (<code>[[CamelCase|lowerCamelCase]]</code> [[पैरामीटर (कंप्यूटर विज्ञान)]] और [[ चर (प्रोग्रामिंग) |चर (प्रोग्रामिंग)]] ) के लिए अनुशंसित है और यह .NET भाषाओं के लिए साझा सम्मेलन है।<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>
+Microsoft .NET अनुशंसा करता है <code>[[CamelCase|UpperCamelCase]]</code>, जिसे अधिकांश पहचानकर्ताओं के लिए पास्कलकेस के रूप में भी जाना जाता है। (<code>[[CamelCase|lowerCamelCase]]</code> [[पैरामीटर (कंप्यूटर विज्ञान)]] और वरिएबल [[ चर (प्रोग्रामिंग) |(प्रोग्रामिंग)]] ) के लिए अनुशंसित है और यह .NET लैंग्वेज के लिए साझा सम्मेलन है।<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>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>.
+विधि नाम कोलन द्वारा पृथक किए गए विभिन्न लोअरकैमलकेस भागों का उपयोग करते हैं जो तर्कों को सीमित करते हैं, जैसे: <code>application:didFinishLaunchingWithOptions:</code>, <code>stringWithFormat:</code> और <code>isRunning</code>.
 ===पास्कल, मोडुला-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>
+विर्थियन लैंग्वेज सामान्यतः पास्कल, मोडुला-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>-जो लोअरकेस हैं।
+पर्ल सम्मेलनों के लिए अपनी सी विरासत से कुछ संकेत लेता है। स्थानीय रूप से स्कोप्ड वेरिएबल और सबरूटीन नाम इनफ़िक्स अंडरस्कोर के साथ लोअरकेस में हैं। प्राइवेट माने जाने वाले सबरूटीन्स और वेरिएबल्स के पहले अंडरस्कोर लगा होता है। पैकेज वेरिएबल शीर्षक आवरण वाले हैं। घोषित कांस्टेंट सभी अधिकतम सीमाएँ हैं। प्राग्माटा को छोड़कर पैकेज के नाम कैमल केस हैं—उदाहरण के लिए, <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>
@@ Line 277: / Line 274: @@
 ===[[पीएचपी]]===
-PHP सिफ़ारिशें PSR-1 (PHP मानक सिफ़ारिश 1) और PSR-12 में शामिल हैं।<ref name=PSR>{{Cite web | title = PHP मानक सिफ़ारिशें| url = http://www.php-fig.org/psr/}}</ref> PSR-1 के अनुसार, क्लास के नाम पास्कलकेस में होने चाहिए, क्लास स्थिरांक MACRO_CASE में होने चाहिए, और फ़ंक्शन और विधि के नाम कैमलकेस में होने चाहिए।<ref>{{Cite web|url=https://www.php-fig.org/psr/psr-1/|title = PSR-1: Basic Coding Standard - PHP-FIG}}</ref>
+PHP सिफ़ारिशें PSR-1 (PHP स्टैण्डर्ड सिफ़ारिश 1) और PSR-12 में सम्मिलित हैं।<ref name=PSR>{{Cite web | title = PHP मानक सिफ़ारिशें| url = http://www.php-fig.org/psr/}}</ref> PSR-1 के अनुसार, क्लास के नाम पास्कलकेस में होने चाहिए, क्लास कांस्टेंट MACRO_CASE में होने चाहिए, और फ़ंक्शन और विधि के नाम कैमलकेस में होने चाहिए।<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> अन्य नामों के लिए.
+[[पायथन (प्रोग्रामिंग भाषा)|पायथन (प्रोग्रामिंग लैंग्वेज)]] और [[रूबी (प्रोग्रामिंग भाषा)|रूबी (प्रोग्रामिंग लैंग्वेज)]] दोनों अनुशंसित हैं <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=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> यह मार्गदर्शिका फ़ाइल नामों में विशेष वर्णों से बचने और वेरिएबल और फ़ंक्शन नामों के लिए केवल संख्याओं, अक्षरों और अंडरस्कोर का उपयोग करने की अनुशंसा करती है। फिट_मॉडल.आर.
+जबकि [[आर (प्रोग्रामिंग भाषा)|आर (प्रोग्रामिंग लैंग्वेज)]] के लिए कोई आधिकारिक स्टाइल गाइड नहीं है, आर-गुरु हैडली विकम की टिडीवर्स स्टाइल गाइड अधिकांश उपयोगकर्ताओं के लिए स्टैण्डर्ड निर्धारित करती है।<ref name=tidyverse>[https://style.tidyverse.org/ Style Guide for RCode ]</ref> यह मार्गदर्शिका फ़ाइल नामों में विशेष वर्णों से बचने और वेरिएबल और फ़ंक्शन नामों के लिए केवल संख्याओं, अक्षरों और अंडरस्कोर का उपयोग करने की अनुशंसा करती है। फिट_मॉडल.आर.
 ===राकू===
-[[राकू (प्रोग्रामिंग भाषा)]] कमोबेश पर्ल जैसी ही परंपराओं का पालन करती है, सिवाय इसके कि यह इन्फ़िक्स हाइफ़न की अनुमति देती है <code>-</code> या धर्मोपदेश <code>'</code> (या एकल उद्धरण) पहचानकर्ता के भीतर (लेकिन पंक्ति में दो नहीं), बशर्ते कि इसके बाद वर्णमाला वर्ण हो। राकू प्रोग्रामर अक्सर अपने पहचानकर्ताओं में कबाब केस का उपयोग करते हैं; उदाहरण के लिए,
+[[राकू (प्रोग्रामिंग भाषा)|राकू (प्रोग्रामिंग लैंग्वेज)]] कमोबेश पर्ल जैसी ही परंपराओं का पालन करती है, सिवाय इसके कि यह इन्फ़िक्स हाइफ़न की अनुमति देती है <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>
@@ Line 296: / Line 293: @@
 ===जंग ===
-रस्ट (प्रोग्रामिंग भाषा) अनुशंसा करता है <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>
+रस्ट (प्रोग्रामिंग लैंग्वेज) अनुशंसा करता है <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 के साथ प्रमुख अद्यतन ने नेमिंग कन्वेंशन को स्थिर कर दिया <code>lowerCamelCase</code> वरिएबल और फ़ंक्शन घोषणाओं में। कांस्टेंट को सामान्यतः एनम प्रकार या स्थिर मापदंडों द्वारा परिभाषित किया जाता है जिन्हें इस तरह भी लिखा जाता है। क्लास और अन्य ऑब्जेक्ट प्रकार की घोषणाएँ हैं <code>UpperCamelCase</code>.
-स्विफ्ट 3.0 के अनुसार सभी तृतीय पक्ष एपीआई में एपीआई नामकरण और घोषणा सम्मेलनों को मानकीकृत करने के प्रयास में भाषा के लिए स्पष्ट नामकरण दिशानिर्देश बनाए गए हैं।
+स्विफ्ट 3.0 के अनुसार सभी तृतीय पक्ष एपीआई में एपीआई नेमिंग और घोषणा सम्मेलनों को मानकीकृत करने के प्रयास में लैंग्वेज के लिए स्पष्ट नेमिंग दिशानिर्देश बनाए गए हैं।
   <ref>{{Cite web | title = स्विफ्ट.ओआरजी एपीआई डिज़ाइन दिशानिर्देश| url = http://swift.org/documentation/api-design-guidelines/#conventions }}</ref>
 ==यह भी देखें==
-*:श्रेणी:[[नामकरण परंपरा]]एँ
+*:श्रेणी:[[नामकरण परंपरा|नामकरण]] कन्वेंशन
 *[[चेकस्टाइल]]
 *[[कोडिंग कन्वेंशन]]
 *[[स्थैतिक कोड विश्लेषण के लिए उपकरणों की सूची]]
 *[[ नाम स्थान ]]
-*नामकरण परंपरा
+*नेमिंग कन्वेंशन
 *[[सिगिल (कंप्यूटर प्रोग्रामिंग)]]
-*सिंटेक्स (प्रोग्रामिंग भाषाएँ)
+*सिंटेक्स (प्रोग्रामिंग लैंग्वेज)
 ==संदर्भ==

Anonymous

Search