वर्डप्रेस [गाइड] के लिए कोडिंग मानक

इसका कारण यह है कि हमारे पास कोडिंग मानक हैं (केवल वर्डप्रेस के लिए नहीं) प्रोग्रामर के लिए एक परिचित वातावरण बनाएं किसी प्रोजेक्ट पर काम करना। वर्डप्रेस विशेष रूप से उत्पादों की एक विस्तृत विविधता को शामिल करता है। मूल से ही विषयों और प्लगइन्स के लिए, देखने के लिए बहुत कुछ है - और बहुत कुछ मिला हुआ है.

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

वर्डप्रेस में सामंजस्य की आवश्यकता राज्य द्वारा बढ़ाई जाती है जिसमें कोडबेस है। वर्डप्रेस एक सख्त ऑब्जेक्ट उन्मुख दृष्टिकोण का पालन नहीं करता है और एक एमवीसी पैटर्न का उपयोग नहीं करता है। बिना किसी अपवाद के (जैसे लारवेल) ओओपी और एमवीसी दिशानिर्देशों का पालन करने वाली परियोजनाओं में स्थिरता और सर्वोत्तम प्रथाएं हैं “में बेक किया हुआ” उनकी संरचना के कारण.

वर्डप्रेस दुर्भाग्य से स्पेगेटी कोडिंग, उर्फ ​​के लिए परिपक्व है जो चाहो कर लेना. सर्वोत्तम प्रथाओं को लागू करना मुश्किल है क्योंकि खराब कोड को लागू करने वाले उत्पाद बस (सतह पर) काम कर सकते हैं.

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

Hongkiat.com पर अधिक:

• वेब डेवलपर्स के लिए 10 सबसे बुरे सपने
• 5 कारण क्यों CSS सभी की सबसे कठिन भाषा हो सकती है
• 30 आम प्रतिक्रियाएँ प्रोग्रामर जब चीजें गलत हो जाती हैं

मानकों पर कुछ नोट्स

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

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

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

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

वर्डप्रेस कोडिंग मानक

अभी वर्डप्रेस में चार गाइड हैं, जो इस्तेमाल की जाने वाली प्रत्येक प्रमुख भाषा के लिए हैं: PHP, HTML, जावास्क्रिप्ट और CSS। वे ज्ञान के एक बड़े शरीर का एक हिस्सा बनाते हैं, कोर योगदानकर्ता पुस्तिका। सब कुछ के माध्यम से जाने में थोड़ा समय लगेगा इसलिए मैंने चार भाषाओं के कुछ स्निपेट पर प्रकाश डाला है जिन्हें मैं अक्सर लोगों को गलत होते देखता हूं.

पीएचपी

PHP वर्डप्रेस की मुख्य भाषा है और एक काफी शिथिल टाइप की भाषा है जो इसे नियमन के लिए परिपक्व बनाती है.

ब्रेस स्टाइल्स

ब्रेसिज़ शुरू करना हमेशा लाइनों के अंत में रखा जाना चाहिए। संबंधित बयान पिछले समापन ब्रेस के रूप में एक ही लाइन पर रखा जाना चाहिए। यह एक कोड उदाहरण के साथ सबसे अच्छा प्रदर्शन किया गया है:

if (कंडीशन) // डू समथिंग पर्सिफ़ (कंडीशन) // डू समथिंग बाकी // डू समथिंग

उदार अंतरिक्ष उपयोग

मैं स्क्वैश अप कोड का प्रशंसक नहीं हूं (मेरी बुरी नजर है) तो यह एक है जिसे मैं विशेष रूप से लागू करना पसंद करता हूं। बाद में स्पेस दें अल्पविराम के, और दोनों तरफ तार्किक, तुलना, तार तथा असाइनमेंट ऑपरेटर, बाद अगर, elseif, के लिये, प्रत्येक के लिए तथा स्विच बयान और इतने पर.

यह कहना आसान है कि कहाँ स्थान नहीं जोड़े जाने चाहिए! केवल एक बार जब आपको रिक्त स्थान नहीं जोड़ना चाहिए typecasting या संदर्भित सरणियाँ.

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

फ़ंक्शन my_function ($ complete_array = null, $ key_1 = 4, $ key_2 = 'bar') if (null == $ complete_array) $ final_array = $ complete_array;  और $ key_1 = (पूर्णांक) $ key_1; $ फाइनल_अरे [0] = 'यह'; $ Final_array [$ key_1] = 'है'; $ Final_array [$ key_2] = 'a'; $ फाइनल_अरे ['अंतिम'] = 'उदाहरण';  रिटर्न $ फ़ाइनल_अरे; 

नामकरण की परंपरा

यह एक के लिए उपयोग करने के लिए कठिन हो सकता है, खासकर यदि आप विभिन्न वातावरण से आते हैं। संक्षेप में:

• चर नाम होना चाहिए सभी छोटे अक्षर, अंडरस्कोर के साथ अलग हुए शब्द
• वर्ग के नाम उपयोग करना चाहिए बड़े शब्द अंडरस्कोर द्वारा अलग किया गया. परिवर्णी शब्द सब होना चाहिए अपरकेस
• स्थिरांक होना चाहिए सभी बड़े, अंडरस्कोर द्वारा भाला
• फ़ाइल नाम होना चाहिए सभी छोटे अक्षर, डैश के साथ अलग

योदा स्थितियां

आपके द्वारा उपयोग किए जाने के अलावा आसपास की स्थितियों को लिखने से पार्सिंग त्रुटियों को रोका जा सकेगा। यह थोड़ा अजीब लगता है लेकिन यह बेहतर कोड है.

अगर ('डैनियल' === $ नाम) गूंज 'लेख आप लिखेंगे'; 

एचटीएमएल

HTML में यह नहीं है कि इसके साथ जुड़े कई नियम हैं, मैं चीजों को अधिक मॉड्यूलर बनाने के लिए काफी आ सकता हूं। HTML लिखते समय आपको केवल पांच नियमों का पता होना चाहिए:

1. आपका कोड W3C सत्यापनकर्ता के विरुद्ध मान्य होना चाहिए.
2. स्वयं-बंद करने वाले HTML टैग्स में फ़ॉरवर्ड स्लैश से पहले बिल्कुल एक स्थान होना चाहिए (यह वह है जिसे मैं व्यक्तिगत रूप से घृणा करता हूं, लेकिन यह एक डब्ल्यू 3 सी विनिर्देश है, न कि केवल एक वर्डप्रेस पालतू पशु की खाल)
3. विशेषताएँ और टैग सभी लोअरकेस होना चाहिए। एकमात्र अपवाद तब होता है जब विशेषता मान मानव उपभोग के लिए होता है, जिस स्थिति में उन्हें स्वाभाविक रूप से टाइप किया जाना चाहिए.
4. सभी विशेषताओं का एक मूल्य होना चाहिए और उद्धृत किया जाना चाहिए (लेखन सही नहीं है)
5. टैब का उपयोग करके इंडेंटेशन प्राप्त किया जाना चाहिए और तार्किक संरचना का पालन करना चाहिए.

सीएसएस

CSS एक दूसरी शिथिल टाइप की भाषा है इसलिए यहाँ भी बहुत काम किया जाना है। फिर भी, मानक कोडर्स पर बहुत आसान हो जाते हैं.

चयनकर्ताओं

चयनकर्ताओं को आवश्यक रूप से योग्य होना चाहिए, मानवीय रूप से पठनीय होना चाहिए, डैश के साथ अलग-अलग शब्दों के साथ सभी लोअरकेस होना चाहिए, और विशेषता चयनकर्ताओं को दोहरे उद्धरण चिह्नों का उपयोग करना चाहिए। यहाँ एक संक्षिप्त उदाहरण है:

इनपुट [प्रकार = "पाठ"], इनपुट [प्रकार = "पासवर्ड"], नाम-क्षेत्र पृष्ठभूमि: # f1f1f1; 

संपत्ति का आदेश

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

यादृच्छिकता का सबसे बड़ा कारण है “ओह मुझे भी एक मार्जिन जोड़ने की जरूरत है” और फिर इसे नीचे तक जोड़ने के लिए आगे बढ़ें। अतिरिक्त .3 सेकंड लें और नियम को तार्किक स्थान पर जोड़ें.

• प्रदर्शन
• पोजिशनिंग
• बॉक्स मॉडल
• रंग और टाइपोग्राफी
• अन्य

.प्रोफ़ाइल-मोडल प्रदर्शन: ब्लॉक; स्थिति: पूर्ण; बाएं: 100px; शीर्ष: गुणित 90px; पृष्ठभूमि: # ff9900; रंग: #fff; 

मूल्य स्वरूपण

यह एक ऐसी जगह है जहां मैं विसंगतियों को देखकर विशेष रूप से नफरत करता हूं। यदि आप दिशानिर्देशों का पालन नहीं करते हैं, तो यह मूल्य से पहले कभी-कभी किसी स्थान को देखने से बेहतर है; कभी-कभी शॉर्टहैंड का उपयोग करना, कभी-कभी नहीं; कभी-कभी 0 मानों पर इकाइयों का उपयोग करना, कभी-कभी नहीं, आदि.

मूल्य स्वरूपण बहुत जटिल है लेकिन यह स्वाभाविक रूप से कुछ अभ्यास के साथ आता है. अपने मूल्यों को प्रारूपित करने के लिए कोडेक्स में सटीक गाइड पर एक नज़र डालें.

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

मेरे अनुभव में जावास्क्रिप्ट को सभी जगह पर जाने का सबसे अधिक खतरा है। जबकि कई डेवलपर्स को पता है कि जावास्क्रिप्ट की काफी मात्रा धीरे-धीरे सीखी गई थी, HTML, CSS और PHP के बाद। जब आप एक नई भाषा के साथ शुरुआत कर रहे होते हैं तो आप बहुत अधिक गलतियाँ करते हैं और यदि वे गलतियाँ घातक त्रुटियों का कारण नहीं बनती हैं, तो वे आप में उलझ सकती हैं.

कई मामलों में मानक एक लाइन सीमा या स्थिति को संदर्भित करते हैं “यदि कोई रेखा बहुत लंबी नहीं है”. यह jQuery स्टाइल गाइड को संदर्भित करता है जो एक लगाता है लाइनों पर 100-वर्ण की सीमा. वर्डप्रेस गाइड jQuery गाइड पर आधारित है, इसलिए यह एक अच्छा विचार है कि इसे भी पढ़ें.

अर्धविराम

यह सबसे सरल नियम है, लेकिन एक है जिसे अक्सर अनदेखा किया जाता है। कभी नहीं, कभी भी, एक अर्धविराम को केवल इसलिए छोड़ दें क्योंकि आपका कोड इसके बिना काम करेगा। यह सिर्फ मैला है.

इंडेंट

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

ब्रेकिंग लाइन्स

लंबे तारों को तोड़ते समय, ऑपरेटर के बाद हमेशा लाइन को तोड़ें, एक चर के बारे में लटका मत छोड़ो. यह पहली नज़र में स्पष्ट करता है कि लाइन टूट गई है और आप सिर्फ अर्धविराम नहीं भूल गए हैं.

इसके अलावा, यदि कोई स्थिति लंबी है, तो इसे कई लाइनों में तोड़ दें और इसके पहले एक अतिरिक्त टैब जोड़ें। यह मेरी आँखों के लिए बहुत ही अजीब लगता है लेकिन स्थिति और शरीर के बीच जो अलगाव होता है वह बहुत दिखाई देता है.

अगर (फर्स्टकॉन्डीशन () && सेकंडकॉन्डिशन () && थर्डकॉन्डिशन ()) var html = 'इस लाइन में' + n + 'शब्द हैं, तो इसे' + 'एक ऑपरेटर के बाद तोड़ दिया जाना चाहिए; 

jQuery Iteration

मानकों के अनुसार jQuery पुनरावृत्ति (JQuery.each ()) केवल jQuery वस्तुओं पर इस्तेमाल किया जाना चाहिए। आपको बेसिक का उपयोग करना चाहिए के लिये, अंदर के लिए, जबकि अन्य संग्रह पर पुनरावृत्ति के लिए जावास्क्रिप्ट में छोरों.

निष्कर्ष

नोट करने और रखने के लिए बहुत कुछ है और कोई रास्ता नहीं है कि कोई एक बार में यह सब लागू कर सके। आपको अपना कोड मानकों के अनुसार जितना संभव हो उतना करीब लेना चाहिए और उनका ठीक से पालन करते हुए काम करना चाहिए.

मेरी राय में संगति सबसे महत्वपूर्ण नियम है. आधे रास्ते को स्विच करने की तुलना में लगातार कुछ गलत करना बेहतर है। यह विशेष रूप से स्वरूपण प्रथाओं के साथ सच है क्योंकि ये आपके कोड की कार्यक्षमता को प्रभावित नहीं करते हैं - और अधिकांश भाग के लिए - बाद में आसानी से बैच-बदला जा सकता है.

क्या आपको कोडिंग मानकों के एक तत्व से नफरत है, क्या आपको लगता है कि कुछ जोड़ा जाना चाहिए? हमें टिप्पणियों में बताएं!