WordPress कोडिंग स्टैंडर्ड्स: नेमिंग कन्वेंशन और फंक्शन आर्गुमेंट

इस सीरीज में, हम WordPress कोडिंग स्टैंडर्ड्स में एक गहरा गोता ले रहे हैं - विशेष रूप से, PHP कोडिंग स्टैंडर्ड्स - सुसमाचार प्रचार (evangelize) और समझने के लिए कि गुणवत्ता वाले WordPress कोड कैसे लिखे जाना चाहिए।

इस तथ्य के बावजूद कि यह WordPress डेवलपर हैंडबुक के भीतर डॉक्युमेंटेड है, मुझे लगता है कि कुछ चीजे जैसी है वैसी क्यों है इसके पीछे का तर्क (rationale) को समझने के बारे में कुछ कहा जाना है।

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

इस पोस्ट में, हम नेमिंग कन्वेंशन और फंक्शन आर्ग्यूमेंट्स को संभालने के तरीके पर एक नज़र डालने जा रहे हैं।

नेमिंग की परंपरा

कोडिंग स्टैंडर्ड्स में उल्लिखित बिंदुओं पर विस्तार के लिए समय खर्च करने से पहले, यह समझना महत्वपूर्ण है कि आप किस प्लेटफॉर्म के साथ काम कर रहे हैं, इस पर ध्यान दिए बिना लिखित कोड में नेमिंग का कन्वेंशन महत्वपूर्ण है।

आखिरकार, नेमिंग कन्वेंशन - भले ही वे क्लासेज, फंक्शन्स, वेरिएबल, ऐट्रिब्यूट्स, या आर्ग्यूमेंट्स के लिए हों - उन्हें उस उद्देश्य के बारे में जानने में मदद करनी चाहिए जो वे करते हैं।

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

जैसे की कोडिंग स्टैण्डर्ड बताते हैं:

वेरिएबल नामों को बेकार में संक्षिप्त (abbreviate) न करें; कोड को स्पष्ट और सेल्फ-डोक्युमेंटिंग होने दें।

कोड के किस हिस्से पर आप काम कर रहे हैं, इस पर ध्यान दिए बिना यह एक अच्छा रूल ऑफ़ थंब है।

क्लास के नाम

जब WordPress के साथ काम करने की बात आती है, तो इसकी सम्भावना नहीं है की आपको क्लासेज का सामना करना पड़ेगा जबतक कि आप दो चीजों में से एक नहीं कर रहे हैं:

• थीम या एप्लिकेशन के साथ काम करने के लिए एक कस्टम लाइब्रेरी लिखना
• OOP-आधारित प्लगइन लिखना

यदि आप थीम पर बस काम कर रहे हैं, तो आप फंक्शन्स के एक सेट के साथ काम करने की अधिक संभावना रखते हैं - हम कुछ क्षणों में इसके बारे में बात करेंगे।

लेकिन उन लोगों के लिए जो प्लगइन या अपने लाइब्रेरीज के साथ काम कर रहे हैं, यह याद रखना महत्वपूर्ण है कि क्लासेज आम तौर पर संज्ञा (nouns) होनी चाहिए - उन्हें उस उद्देश्य का प्रतिनिधित्व करना चाहिए जो वे समाहित (encapsulate) करते हैं और उन्हें आदर्श रूप से एक चीज करनी चाहिए और इसे अच्छी तरह से करना चाहिए।

उदाहरण के लिए, यदि आपके पास Local_File_Operations नामक एक क्लास है तो यह फ़ाइलों को पढ़ने और लिखने के लिए ज़िम्मेदार हो सकती है। फ़ाइलों को पढ़ने और लिखने के साथ-साथ, रिमोट फ़ाइलों को रिट्रीव करने के लिए यह ज़िम्मेदार नहीं होनी चाहिए।

WordPress कोडिंग स्टैंडर्ड्स के अनुसार, क्लासेज को निम्नलिखित कन्वेंशन का पालन करना चाहिए:

• क्लास के नामों को अंडरस्कोर द्वारा अलग किए गए कैपिटलाइज़ शब्दों का उपयोग करना चाहिए।
• किसी भी शब्दकोष (acronym) सभी अपर केस होने चाहिए।

आसान, है न?

व्यावहारिक रूप से बोलते हुए, यह निम्न की तरह दिखेगा:

• class Local_File_Operations {}
• class Remote_File_Operations {}
• class HTTP_Request {}
• class SQL_Manager {}

दोहराने के लिए: क्लासेज भी संज्ञाएं (nouns) होनी चाहिए और उन्हें एक ही उद्देश्य का वर्णन करना चाहिए जिसे वह सर्व कर रही हैं।

फंक्शन नाम

जैसा कि पहले उल्लेख किया गया है, यदि क्लासेज संज्ञाएं हैं जो आदर्श रूप से एक आईडिया या सिंगल उद्देश्य का प्रतिनिधित्व करती हैं, तो उनके मेथड्स को वह एक्शन्स होने चाहिए जिन्हें वे लेने में सक्षम हैं। इस प्रकार, उन्हें क्रियाएं (verbs) होनी चाहिए - उन्हें इंगित करना चाहिए कि जब भी उन्हें बुलाया जाता है तो कौन सा एक्शन लिया जाएगा।

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

कोड में, यह कुछ ऐसा दिख सकता है:

// The class definition
class Local_File_Manager {

  public function open_file( $filename ) {
		// Function implementation
	}

}

// How we'd use this code
$file_manager = new Local_File_Manager();
$file_manager->open_file( 'foo.txt' );

बेशक, यह अभी भी कवर नहीं करता है कि WordPress डेवलपमेंट के संदर्भ में फंक्शन्स को कैसे लिखा जाना चाहिए। कोडिंग स्टैंडर्ड्स स्टेट:

वेरिएबल, एक्शन, और फ़ंक्शन नामों में लोअरकेस अक्षर का उपयोग करें (कभी camelCase नहीं)। अंडरस्कोर के माध्यम से शब्द अलग करें। वेरिएबल नामों को संक्षेप में न करें; कोड को स्पष्ट और स्वयं-डोक्युमेंटिंग होने दें।

कन्वेंशन का पहला हिस्सा समझने में काफी आसान है; हालांकि, मुझे लगता है कि जब डेवलपर्स सक्षम होते हैं तो शॉर्टकट लेने की प्रवृत्ति होती है। "आह," हम सोचते हैं, "$str यहां समझ में आता है, और $number यहां समझ में आता है।"

बेशक, हमेशा कुछ खराब भी होता हैं - कुछ डेवलपर अपने वेरिएबल नामों के लिए सिंगल करैक्टर का उपयोग करने का सहारा लेते हैं (जो आम तौर पर केवल लूप के भीतर ही स्वीकृत होते है।)

जैसे कोडिंग मानदंड बताते हैं: वैरिएबल नामों को बिना कारण के संक्षेप में न करें। कोड को स्पष्ट और स्वयं-डोक्युमेंटिंग होने दें।

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

वैसे भी, बॉटम लाइन आपके मेथड के नाम को कम करने के लिए है, सभी कैमल केसिंग से बचें, स्पेस से अलग करें, और अपने वेरिएबल को नाम देते समय जितना संभव हो उतना स्पेसिफिक हो।

वेरिएबल नाम

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

• लोअर केस (बनाम कैमलकेस)
• अंडरस्कोर के साथ स्पेस अलग करें

एक अन्य कन्वेंशन जो कुछ डेवलपर्स उपयोग करते है वह Hungarian नोटेशन के रूप में जाना जाता है, जहां उस प्रकार की वैल्यू जो वैरिएबल स्टोर करता है को वैरिएबल के सामने प्रीफिक्स कर दिया जाता है।

उदाहरण के लिए:

• स्ट्रिंग्स को अक्सर $str_firstname के रूप में दर्शाया जाएगा
• नंबर को $i_tax या $num_tax के रूप में लिखा जाएगा
• Arrays $arr_range के रूप में लिखा जा सकता है
• ...और भी इसी तरह से

ईमानदारी से, कोडिंग कन्वेंशन इस बारे में कुछ भी नहीं कहते हैं। एक ओर, मुझे लगता है कि यह कोड के ओवरआल स्कोप में क्लीनर कोड बनाता है, लेकिन ऐसे कई डेवलपर हैं जो हंगेरियन नोटेशन को नापसंद करते हैं।

चूंकि कोडिंग कन्वेंशन उनके बारे में कुछ भी नहीं कहते है, इसलिए मैं उन्हें रेकमेंड करने में संकोच करता हूं क्योंकि मैं यथासंभव स्टैंडर्ड्स के करीब रहना चाहता हूं। इस प्रकार, मुझे रेकमेंड करना है कि कोडिंग स्टैंडर्ड्स का पालन करना सबसे अच्छा है।

फ़ाइल के नाम

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

कोडिंग स्टैंडर्ड्स के मुताबिक:

फ़ाइलों को लोअरकेस अक्षरों का उपयोग करके वर्णनात्मक (descriptively) रूप से नामित किया जाना चाहिए। हाइफ़न से शब्दों को अलग करना चाहिए।

हमारे पिछले उदाहरण के अनुरूप बने रहने के लिए, मान लीजिए कि हम Local_File_Operations के साथ काम कर रहे हैं तो फ़ाइल को class-local-file-operations.php नाम दिया जाएगा।

काफी आसान।

इसके बाद, अगर आप Instagram_Foo नामक प्लगइन पर काम कर रहे हैं तो फ़ाइल को instagram-foo.php नाम दिया जाना चाहिए; हालांकि, यह ध्यान देने योग्य है कि यदि आप अपने प्लगइन को डेवेलप करने के लिए कुछ प्रकार के उन्नत तरीकों का उपयोग करते हैं जैसे प्लगइन क्लास फ़ाइल को अपनी फ़ाइल में रखना और फिर इसे किसी अन्य फ़ाइल का उपयोग करके लोड करना, तो आपकी फ़ाइल का स्ट्रक्चर हो सकता है:

• class-instagram-foo.php
• instagram-foo.php

जहां instagram-foo.php class-instagram-foo.php लोड करने के लिए ज़िम्मेदार है। बेशक, यह केवल तभी समझ में आता है जब आप अपने WordPress प्लगइन लिखते समय OOP का उपयोग कर रहे हों।

फंक्शन के आर्गुमेंट

जब फ़ंक्शन आर्ग्यूमेंट्स को पारित करने की बात आती है, तो यह याद रखना महत्वपूर्ण है कि यदि फ़ंक्शन नाम क्लास द्वारा किए जा रहे फंक्शन्स का वर्णन करते हैं, तो आर्गुमेंट को प्रतिनिधित्व करना चाहिए कि फ़ंक्शन वास्तव में क्या ऑपरेट कर रहा है।

कोडिंग स्टैंडर्ड्स से:

फंक्शन्स को कॉल करते समय स्ट्रिंग वैल्यूज को केवल true और false पर प्राथमिकता दें।

चूंकि फ़ंक्शन में वैल्यूज को पास करते समय बूलियन वैल्यू अस्पष्ट हो सकती हैं, इसलिए यह सुनिश्चित करना मुश्किल हो जाता है कि फ़ंक्शन क्या कर रहा है।

उदाहरण के लिए, ऊपर दिए गए उदाहरण को थोड़ा अलग तरीके से उपयोग करें:

// The class definition
class Local_File_Manager {

	public function manage_file( $filename, true ) {

		if ( true ) {
			// Open the file
		} else {
			// Delete the file
		}

	}

}

// How we'd use this code
$file_manager = new Local_File_Manager();
$file_manager->manage_file( 'foo.txt', true );

कहने से ज्यादा समझना मुश्किल है, ऐसा कुछ करें:

// The class definition
class Local_File_Manager {

	public function open_file( $filename ) {
		// open the file
	}

	public function delete_file( $filename ) {
		// delete the file
	}

}

// How we'd use this code
$file_manager = new Local_File_Manager();
$file_manager->open_file( 'foo.txt' );
$file_manager->delete_file( 'foo.txt' );

इसके शीर्ष पर, याद रखें कि फंक्शन्स में पारित आर्गुमेंट अभी भी वेरिएबल हैं और इसलिए वे वेरिएबल नेमिंग फंक्शन्स के अधीन हैं जिन्हें हमने ऊपर विस्तार से बताया है।

निष्कर्ष

हमने कोडिंग स्टैंडर्ड्स में नेमिंग फंक्शन्स और फ़ंक्शन आर्ग्यूमेंट्स पर एक विस्तृत रूप से नजर डाली है। उम्मीद है कि इसने आपके WordPress कोड के कुछ पहलुओं को सुधारने के लिए न केवल एक गाइड प्रदान करने में मदद की है, बल्कि कुछ प्रथाओं के पीछे तर्कों को समझाया है।

अगले आर्टिकल में, हम WordPress डेवलपमेंट में स्ट्रिंग्स के साथ काम करने के कॉन्टेक्स्ट में सिंगल कोट्स और डबल कोट्स के महत्व पर एक नज़र डालने जा रहे हैं।

इसमें अंतर है कि उन्हें PHP द्वारा कैसे इनकी व्याख्या की जाती है और ऐसी स्थितियां हैं जिनमें आपको एक दूसरे का उपयोग करना चाहिए और हम अगले आर्टिकल में इसकी समीक्षा करेंगे।