प्रोग्रामिंग में नेमिंग कन्वेंशंस सरल भाषा में

This post is also available in: English

सॉफ्टवेयर प्रोग्रामिंग के लिए टेक्स्ट स्क्रिप्ट बनाते समय नेमिंग कन्वेंशंस सामान्य नियम हैं। उनके कई अलग-अलग उद्देश्य हैं, जैसे स्क्रिप्ट में स्पष्टता और एकरूपता जोड़ना, थर्ड-पार्टी ऍप्लिकेशन्स के लिए पठनीयता, और कुछ भाषाओं और ऍप्लिकेशन्स में कार्यक्षमता। वे कॅपिटलाइज़ेशन्स और विराम चिह्न से लेकर कुछ फंक्शन्स को दर्शाने के लिए प्रतीकों और पहचानकर्ताओं को जोड़ने तक हैं। इस लेख में प्रोग्रामिंग में नेमिंग कन्वेंशंस का महत्व समझते हैं।

प्रोग्रामिंग में नेमिंग कन्वेंशंस क्या होता है?

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

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

“पढ़ने में लगने वाले समय (कोड) बनाम लेखन का अनुपात 10 से 1 से अधिक है … (इसलिए) इसे पढ़ने में आसान बनाने से लिखना आसान हो जाता है।” — रॉबर्ट सी मार्टिन

नेमिंग कन्वेंशन के नियम

निम्नलिखित महत्वपूर्ण नियम हैं जिनका उचित नेमिंग कन्वेंशन को लागू करने के लिए पालन किया जाना चाहिए।

1. सुसंगत रहें

यह नियम कहता है कि “प्रति अवधारणा एक शब्द चुनें – पूरे कोड में एक ही अवधारणा का उपयोग करें“।

चीजों को नाम देने का एक मानक तरीका खोजने की कोशिश करें, शब्द चयन के साथ यथासंभव सुसंगत रहें। वही बातें कहने के लिए समान शब्दों का प्रयोग करने का प्रयास करें। उदाहरण के लिए, हम शब्दों या शब्दों के समूहों को अलग करने के लिए “लोअर कैमलकेस” नामकरण और अंडरस्कोर का उपयोग करते हैं।

उदाहरण के लिए

fetchFirstName() {...}
getFirstName() {...}
retrieveFirstName() {...}

उपरोक्त मेथड्स के तीनों नाम समान हैं और एक ही ऑपरेशन के रूप में व्याख्या की जा सकती है। इससे कोई फर्क नहीं पड़ता कि हम वास्तव में किसे चुनते हैं, परन्तु यह महत्वपूर्ण है कि हम पूरे कोड में सुसंगत हों।

यदि हम तय करते हैं कि fetch दूरस्थ रूप से डेटा (रिमोट डेटा) का अनुरोध करेगा, तो हमें उदाहरण के लिए fetchFirstName, fetchLastName और fetchCustomerAddress के लिए उस परंपरा का पालन करना चाहिए।

2. संक्षिप्त और संक्षिप्त शब्दों से बचें

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

दूसरी ओर, कुछ संक्षिप्ताक्षर और परिवर्णी शब्द IT/कंप्यूटर/कोडिंग सामान्य भाषा का हिस्सा हैं और कभी-कभी गैर-संक्षिप्त संस्करण की तुलना में बेहतर जाने जाते हैं। उदाहरण के लिए, “Identification” के लिए “ID”, “Megabyte” के लिए “MV”, “Graphic User Interface” के लिए “GUI”, “Application Programming Interface” के लिए “API”, और अन्य जैसे “SQL”, “HTML” , “REST”, “CMS”, “ERP”, आदि। ये संक्षिप्त और संक्षिप्त शब्द स्वीकार्य हो सकते हैं। वास्तविक लक्ष्य अमानक संक्षिप्ताक्षरों और समरूपों से बचना है।

यहां लंबे नामों का उपयोग करने के लिए प्रतिकूल प्रतीत हो सकता है, खासकर जब से आज के विकास परिवेश सभी स्वत: पूर्णता सुविधाएं और टेक्स्ट विस्तारक कार्यक्रम प्रदान करते हैं। हालाँकि, बहुत लंबे नाम होने से भी एक समस्या हो सकती है। कुछ डेवलपमेंट एनवायरनमेंट, जैसे कि FileMaker, इन नामों को छोटा कर सकते हैं, जिससे उन्हें पढ़ना मुश्किल हो जाता है। अंतिम लक्ष्य छोटे नामों पर समझने योग्य कोड को प्राथमिकता देते हुए एक सुखद माध्यम खोजना है।

3. अर्थपूर्ण बनें

मनमानी श्रृंखला और शब्दों से बचें जो भ्रम पैदा कर सकते हैं। चीजों का नामकरण करते समय समाधान संदर्भ को ध्यान में रखना महत्वपूर्ण है। उदाहरण के लिए, एक पूरी तरह से मनमाना चर नाम जिसका समाधान से कोई संबंध नहीं है, वांछनीय नहीं है।

इस नियम का एक संभावित अपवाद यह है कि चर i और j अक्सर लूप काउंट के लिए उपयोग किए जाते हैं। हम अनुशंसा करते हैं कि आप अपने कोड में अर्थ जोड़ने के लिए यह उल्लेख करें कि यह किस प्रकार की गणना है, जैसे कि userList_loopCount, या किसी कमेंट में इसका उल्लेख करके।

इसे समझने के लिए निम्नलिखित उदाहरण लेते हैं।

स्पष्ट रूप से, आप देख सकते हैं कि const users और const friends भ्रमित कर रहे हैं जबकि const NumberOfUsers और const FriendsOfUsers अर्थ को व्यक्त करने में सफल हैं।

हम उस सुविधा या संदर्भ की 100% मानसिकता के साथ कोड लिखते हैं। लेकिन हम भूल जाते हैं कि अगला पाठक एक अलग मानसिकता के साथ आ सकता है, इसलिए हमें यह सुनिश्चित करना चाहिए कि हम अस्पष्टता से बचें।

4. अर्थपूर्ण भेद

इसका तात्पर्य विभिन्न परिस्थितियों में सार्थक शब्दों के प्रयोग से है। इसे समझने के लिए निम्नलिखित उदाहरण को लेते  हैं।

// Function in Class A
function add(x, y) {
 return x + y;
}
// Function in Class B
function add(x) {
 this.items.add(x);
}

Class A में, Add (x, y) फ़ंक्शन 2 नंबर जोड़ रहा है और class B में Add (x) संग्रह में एक तत्व डाल रहा है। दोनों फ़ंक्शन नाम सही हैं, परन्तु उनके कार्यान्वयन को समझे बिना, आप उन्हें समझने और उनका उपयोग करने में सक्षम नहीं होंगे।

इसके लिए एक बेहतर नाम होगा:

add(x, y) – addNumbers(x, y)

add(x) – insertElement(x)

5. डेटा टाइप एन्कोडिंग से बचें

यह एक बेहतर तरीका लग सकता है, परन्तु बेहतर लचीलेपन/विस्तारशीलता के लिए, यह अस्पष्टता अजीब और बनाए रखने में मुश्किल हो सकती है। नाम वास्तविक क्षेत्र या चर प्रकार के कार्यान्वयन विवरण से उच्च स्तर का अमूर्त होना चाहिए।

एक संभावित अपवाद: फाइलमेकर में यह है कि जब हम फ़ील्ड नाम में एक gl_ या g_ उपसर्ग या प्रत्यय जोड़ते हैं, उदाहरण के लिए gUsername। इन मामलों में, यह निर्दिष्ट डेटा प्रकार नहीं है, बल्कि क्षेत्र का दायरा/दृश्यता है, जो एक चर नाम में $ और $$ की तरह है।

6. एक सामान्य और प्रोफेशनल शब्दावली का प्रयोग करें

कुछ प्रोजेक्ट अपने जीवनकाल में कई बार डेवलपर टीमों को बदलते हैं; अन्य क्रॉस-सांस्कृतिक हैं। आपके द्वारा अपने कोड में चुना गया नाम विभिन्न लोगों द्वारा पढ़ा जाएगा, और अलग-अलग लोगों द्वारा अलग-अलग व्याख्या की जा सकती है।

नेमिंग कन्वेंशन सामान्य और यथासंभव प्रोफेशनल होनी चाहिए, और इसमें एक सामान्य भाषा में भाव शामिल नहीं होने चाहिए। यह आक्रामक या बहुत प्रिय भी नहीं होना चाहिए।

7. उच्चारण योग्य नामों का प्रयोग करें

1. इन नामों पर विचार करें

const lblFrtName; // पहले नाम का लेबल

const nowTsMs; // now date timestamp 1980 से मिलीसेकंड में

इस प्रकार के चर नामों का उच्चारण करना कठिन होता है और कोई भी उन्हें याद नहीं रख पाएगा। इसके अलावा, हमारा कोड खोजने योग्य होना चाहिए। जब प्रोग्राम बड़ा और बड़ा हो जाता है तो हम और अधिक खोज करते हैं। बेहतर नामकरण स्केलिंग को आसान बनाता है।

8. आक्रामक न हों

इन नामों पर विचार करें:

function killThemAll();
function whack();
function giveSomeLove();

याद रखें, हम इंटरनेट के युग में जी रहे हैं। आप जिन प्रोजेक्ट्स पर काम करते हैं उनमें से कई ऑनलाइन हो सकती हैं। आप अपने फंक्शन के लिए जो नाम चुनेंगे उसे कई तरह के लोग पढ़ेंगे। एक ही बात की अलग-अलग लोगों द्वारा अलग-अलग व्याख्या की जा सकती है।

नेमिंग कन्वेंशन सामान्य और यथासंभव प्रोफेशनल होनी चाहिए, और इसमें कोई सांस्कृतिक कठबोली शामिल नहीं होनी चाहिए।

9. सकारात्मक रहें

1. निम्नलिखित नामों देखें:

isDisabled, isUndefined, shouldNotShowScreen, avoidBroadcast, broadcastNotArrived

मनुष्य के रूप में, हमें सकारात्मक दृष्टिकोण की बेहतर समझ है, इसलिए हमें अपने द्वारा चुने गए नामों में उनका उपयोग करना चाहिए।

isDisabled बन जाना चाहिए isEnabled

isUndefined बन जाना चाहिए isDefined

shouldNotShowScreen बन जाना चाहिए shouldShowScreen

avoidBroadcast बन जाना चाहिए doBroadcast

broadcastNotArrived बन जाना चाहिए boardcastArrived

10. वर्तनी की गलतियों से बचें

यह नियम हमारे कोड में ही नहीं, दूसरों के साथ हमारे संचार में हर जगह लागू होना चाहिए। वर्तनी की गलतियाँ और व्याकरण संबंधी त्रुटियाँ हमारे कोड को पढ़ने में कठिन बना सकती हैं। यह प्रूफरीडिंग कोड के महत्व पर प्रकाश डालता है।

आम तौर पर प्रयुक्त नेमिंग कन्वेंशंस

एक प्रोग्राम में मापदंडों के नाम अलग-अलग लोगों द्वारा अलग-अलग तरीके से स्टाइल किए जाते हैं, लेकिन व्यवहार में कुछ सबसे सामान्य शैलियाँ हैं:

कैमल केस: प्रत्येक शब्द का पहला अक्षर बड़े अक्षरों में लिखा जाता है जिसमें शब्दों के बीच कोई रिक्त स्थान या प्रतीक नहीं होता है। उदाहरण के लिए  FirstName, ContactNumber, LastName. 

प्रोग्रामिंग में एक भिन्नता सामान्य है जो लोअरकेस से शुरू होती है: iPad, eBay, fileName, userAccount.

पास्कल केस: इसे पास्कल प्रोग्रामिंग भाषा द्वारा लोकप्रिय बनाया गया था और यह कैमल केस का एक सबसेट है जहां शब्द अपरकेस से शुरू होता है। जैसे , FirstName पास्कल केस में है परन्तु firstName नहीं है।

स्नेक केस: वाक्यांशों या मिश्रित शब्दों के शब्दों को अंडरस्कोर से अलग किया जाता है। उदाहरण के लिए first_name, contact_number, last_name.

कबाब केस: यह स्नेक केस के समान है, लेकिन अंडरस्कोर के स्थान पर हाइफ़न का उपयोग किया जाता है। उदाहरण के लिए first-name, contact-number, last-name.

स्क्रीमिंग केस: शब्द सभी बड़े अक्षरों से मिलकर बने होते हैं। उदाहरण के लिए FIRSTNAME, CONTACTNUMBER, LASTNAME.

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

• सिस्टम हंगेरियन, जहां उपसर्ग डेटा प्रकार को इंगित करता है। उदाहरण के लिए intFirstNumber, strFirstName, arrUserNames
• एप्प्स हंगेरियन, जहां उपसर्ग तार्किक (लॉजिकल) उद्देश्य को इंगित करता है। उदाहरण के लिए rowPosition, colPosition, pchName

नेमिंग कन्वेंशंस सुझाव

नेमिंग कन्वेंशंस के लिए कुछ सुझाव निम्नलिखित हैं।

आइडेंटिफायर टाइप	नेमिंग के नियम	उदाहरण
पैकेजेस	एक यूनिक पैकेज नाम का उपसर्ग हमेशा ऑल-लोअरकेस ASCII अक्षरों में लिखा जाता है और यह शीर्ष-स्तरीय डोमेन नामों में से एक होना चाहिए, वर्तमान में com, edu, gov, mil, net, org, या ASO मानक 3166, 1981 द्वारा अंग्रेजी दो-अक्षर कोड का उपयोग करके निर्दिष्ट देशों की पहचान करना।     पैकेज नाम के बाद के घटक संगठन के स्वयं के आंतरिक नेमिंग कन्वेंशंस के अनुसार भिन्न होते हैं। इस तरह के कन्वेंशंस निर्दिष्ट कर सकते हैं कि कुछ डायरेक्टरी के नाम घटक विभाजन, विभाग, परियोजना, मशीन या लॉगिन नाम हो सकते हैं।	com.sun.engcom.apple.quicktime.v2edu.cmu.cs.bovik.cheese
क्लास	class के नाम संज्ञा होने चाहिए, मिश्रित मामले में प्रत्येक आंतरिक शब्द के पहले बड़े अक्षरों में लिखा जाना चाहिए। अपनी class के नामों को सरल और वर्णनात्मक रखने का प्रयास करें। पूरे शब्दों का प्रयोग करें-संक्षिप्त शब्दों और संक्षिप्ताक्षरों से बचें (जब तक कि संक्षिप्त रूप लंबे रूप से अधिक व्यापक रूप से उपयोग नहीं किया जाता है, जैसे कि URL या HTML)।	class Raster;class ImageSprite
इंटरफेसेस	इंटरफ़ेस नामों को क्लास नामों की तरह बड़े अक्षरों में लिखा जाना चाहिए।	interface RasterDelegate;interface Storing;
मेथड्स	मेथड्स क्रिया होनी चाहिए, मिश्रित मामले में पहले अक्षर लोअरकेस के साथ, प्रत्येक आंतरिक शब्द के पहले अक्षर को बड़े अक्षरों में किया जाना चाहिए।	run();runFast();getBackground();
चर(वेरिएबल्स)	चर को छोड़कर, सभी इंस्टैंस, क्लास और क्लास कांस्टेंट मिश्रित मामले में प्रथम अक्षर लोअरकेस के साथ होने चाहिए। आंतरिक शब्द बड़े अक्षरों से शुरू होते हैं। वेरिएबल नेम्स अंडरस्कोर _ या डॉलर चिह्न $ वर्णों से शुरू नहीं होने चाहिए, भले ही दोनों की अनुमति हो।चर(वेरिएबल) नाम छोटे लेकिन अर्थपूर्ण होने चाहिए। एक चर नाम का चुनाव निमोनिक होना चाहिए- जो कि आकस्मिक पर्यवेक्षक को इसके उपयोग के इरादे को इंगित करने के लिए डिज़ाइन किया गया है। एक-वर्ण चर नामों से बचा जाना चाहिए। टेम्पररी वेरिएबल्स के लिए सामान्य नाम हैं i, j, k, m, और n पूर्णांकों के लिए; कैरक्टर्स के लिए c, d, और e।	int             i;char            c;float           myWidth;
कांस्टेंट	डिक्लेअरड क्लास कांस्टेंट  और ANSI कांस्टेंट के चर के नाम अंडरस्कोर (“_”) द्वारा अलग किए गए शब्दों के साथ सभी अपरकेस होने चाहिए। (डिबगिंग में आसानी के लिए ANSI कांस्टेंट से बचा जाना चाहिए।)	static final int MIN_WIDTH = 4;static final int MAX_WIDTH = 999;static final int GET_THE_CPU = 1;

निष्कर्ष

हमें उम्मीद है कि यह लेख जानकारीपूर्ण रहा है और कुछ ऐसा है जिसे आप तुरंत अपने विकास प्रथाओं पर लागू कर सकते हैं। हम कमैंट्स में नेमिंग कन्वेंशंस बनाने के लिए अन्य सर्वोत्तम प्रथाओं को सुनना पसंद करेंगे।

अनुशंसित पठन

• सरल मशीनें – 3 प्रकार के लीवर समझाए गए
• मेसर और लेजर के बीच अंतर
• विद्युत लैंप प्रकार
• आसमान नीले रंग का क्यों होता है?
• 2-स्ट्रोक और 4-स्ट्रोक इंजन के बीच अंतर

आमतौर पर पूछे जाने वाले प्रश्न