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

सामान्य नियम

कोड दोहराव से बचें

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

ढीले युग्मन पर विचार करें

फ़ंक्शंस को स्वतंत्र रूप से काम करना चाहिए, जिसका अर्थ है कि एक संपादन का दूसरों पर बिल्कुल कोई प्रभाव नहीं होना चाहिए जब तक कि इनपुट और आउटपुट समान रहें। प्रत्येक फ़ंक्शन को दूसरों की परिभाषाओं का कोई ज्ञान नहीं होना चाहिए और एक अलग घटक के रूप में काम करना चाहिए। इस स्थिति में, वह केवल अपने मापदंडों को जानता है, और इससे कोई फर्क नहीं पड़ता कि फ़ंक्शन को कौन कॉल करता है, समान इनपुट हमेशा समान परिणाम लौटाते हैं।

घोषणा

सबसे पहले और सबसे महत्वपूर्ण बात, हर समय वेरिएबल घोषित करना याद रखें।
जब कोई वेरिएबल पुन: असाइन नहीं किया जा रहा हो तो कॉन्स्ट कीवर्ड का उपयोग करें। हालाँकि, आप अभी भी वेरिएबल्स के लिए const का उपयोग कर सकते हैं जो ऑब्जेक्ट या सरणियाँ हैं, भले ही आप उनके नेस्टेड तत्वों को पुन: असाइन करने की योजना बना रहे हों।
कृपया मॉड्यूल की आवश्यकता पर ध्यान दें और हमेशा कॉन्स्ट कीवर्ड का उपयोग करके स्थिर चर को परिभाषित करें।
जब आप const का उपयोग नहीं कर सकते तो लेट कीवर्ड का उपयोग करें, और यदि आपको पुराने ब्राउज़र का समर्थन करने की आवश्यकता है तो केवल var कीवर्ड का उपयोग करें।

कार्य

कार्य निम्नलिखित तक सीमित होने चाहिए:

• चार चर
• चार पैरामीटर
• कोड की तीस पंक्तियाँ (टिप्पणियों को अनदेखा करते हुए)
• चार शाखाएँ (यदि-और, जबकि, के लिए, या-और, स्विच-केस)

कोड लाइनें 100 वर्णों तक सीमित होनी चाहिए, और कार्यों को समूहीकृत/व्यवस्थित करने के लिए, संबंधित कार्यों को यथासंभव एक-दूसरे के करीब रखना बेहतर है।
जब भी संभव हो एरो फ़ंक्शन सिंटैक्स को पारंपरिक विकल्प का विशेषाधिकार दें।

स्ट्रिंग्स

सामान्य स्ट्रिंग अक्षर के लिए एकल उद्धरण ' (दोहरे उद्धरण के बजाय ") का उपयोग करें, लेकिन एम्बेडेड चर/अभिव्यक्ति, एकाधिक पंक्ति स्ट्रिंग और एकल उद्धरण वर्ण वाले स्ट्रिंग के लिए, टेम्पलेट अक्षर का उपयोग करें।

नामकरण

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

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

स्थिर चर अपरकेस में होने चाहिए, शब्दों को अंडरस्कोर से अलग किया जाना चाहिए। फ़ंक्शंस, वेरिएबल्स और विधियों को कैमलकेस सिंटैक्स का पालन करना चाहिए, जबकि सीएसएस कक्षाओं और आईडी को कबाब-केस सिंटैक्स का पालन करना चाहिए।

टिप्पणियाँ

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

टिप्पणियों को एक-पंक्ति कोड के बाद रखें जब तक कि पंक्ति की लंबाई 150 वर्णों से अधिक न हो जाए। ऐसे मामलों में, और मल्टी-लाइन कोड के लिए, टिप्पणियों को सबसे ऊपर रखें।

यदि कथनों के संबंध में, टिप्पणियाँ सशर्त कथनों के बाद रखी जानी चाहिए।

if (conditionIsTrue) { // Put your comment here
    doSomeThing();
} else { // Put your comment here
    doSomethingElse();
}

एक-पंक्ति वाली टिप्पणियों के लिए डबल स्लैश // और बहु-पंक्ति वाली टिप्पणियों के लिए /* */ का उपयोग करना याद रखें। एक-पंक्ति कोड या सशर्त कथनों में बहु-पंक्ति टिप्पणियाँ जोड़ते समय, उन्हें /* */ के भीतर रखें ताकि /* कोड के सामने लिखा हो, टिप्पणी निम्नलिखित पंक्ति पर शुरू होती है, और */ एक नई पंक्ति पर लिखी जाती है रेखा।

if (conditionIsTrue) { /*
        Put your comment here
        Put your comment here
    */
    doSomeThing();
}

functionName(parameter), /*
    Put your comment here
    Put your comment here
*/

फ़ंक्शन वर्णनात्मक टिप्पणियाँ

टिप्पणियों को /** */ द्वारा लपेटे गए फ़ंक्शन के शीर्ष पर रखें।

• @param {type} वेरिएबलनाम विवरण का उपयोग करके पैरामीटर का वर्णन करें।
• यदि पैरामीटर एक से अधिक वेरिएबल प्रकार को स्वीकार कर सकता है, तो @param {type1 | का उपयोग करें टाइप2} वेरिएबलनाम विवरण।
• यदि पैरामीटर वैकल्पिक है और अनुपस्थित हो सकता है, तो @param {type} [variableName] विवरण का उपयोग करें।
• यदि पैरामीटर में एक डिफ़ॉल्ट मान है (यह वैकल्पिक होना चाहिए ताकि वास्तव में एक डिफ़ॉल्ट मान हो), @param {type} [variableName='value'] विवरण का उपयोग करें।
• @returns {type} विवरण का उपयोग करके फ़ंक्शन आउटपुट का वर्णन करें।

/**
 * Describing the function here
 * @param {type} normalVariable A normal variable
 * @param {type1 | type2} multiTypeVariable A variable with multiple expected types
 * @param {type} [variableWithDefaultValue="value"] An optional variable that has a default value in case of being absent when calling the function 
 * @param {type} [optionalVariable] An optional variable
 * @returns {type} description
*/
const functionName = (normalVariable, multiTypeVariable, variableWithDefaultValue, optionalVariable) => {
    doSomeThing();
}

req और res पैरामीटर के साथ सर्वर फ़ंक्शन के संबंध में, अनुरोध पैरामीटर का वर्णन करने की कोई आवश्यकता नहीं है; केवल @returns विवरण का उपयोग करके प्रतिक्रिया का वर्णन करें।

/**
 * Describing the function here
 * @returns description
 */
functionName = (req, res) => {
    doSomeThing();
}

आम तौर पर, पैरामीटर्स में req, res, Next, to, और from का वर्णन करने की कोई आवश्यकता नहीं है।

HTML फ़ाइलों में, कोड के विभिन्न भागों को अलग करने के लिए का उपयोग करें; इसलिए उपयोगकर्ता प्रत्येक भाग को आसानी से पहचान सकता है।

यदि आप कोड की एक पंक्ति के बीच में टिप्पणियाँ लिखते हैं, तो /* */ का उपयोग करें।

const calc_result = (firstNumber * secondNumber)/* Explain the reason for the multiplication */   thirdNumber;

खरोज

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

आदेश

• नेवला स्कीमा के चर और घटकों के Vue प्रतिक्रियाशील स्थिति को वर्णमाला क्रम में क्रमबद्ध करें, लेकिन बाकी समय के लिए पंक्तियों को सबसे छोटी से सबसे लंबी तक क्रमित करें।
• रूट विधियों को पुट, गेट, पोस्ट और डिलीट के क्रम में व्यवस्थित करें, जबकि प्रत्येक स्वयं वर्णमाला क्रम में है, और सभी रूटों को उनके यूआरएल के आधार पर समूहीकृत किया जाना चाहिए।

लपेटें

हालांकि, ये अब तक की सबसे अच्छी सलाह नहीं हैं, मेरा मानना ​​है कि ये स्वच्छ कोड सिद्धांतों को सीखने में रुचि रखने वाले किसी भी व्यक्ति के लिए एक ठोस शुरुआती बिंदु प्रदान करते हैं।
इसके अलावा, हालाँकि इन नियमों का सख्ती से पालन करना शुरू में चुनौतीपूर्ण लग सकता है, अभ्यास के साथ यह और अधिक सरल हो जाता है।

दीर्घकालिक कोडबेस पर काम करते समय वर्तमान परियोजना के दिशानिर्देशों पर टिके रहने की आवश्यकता पर जोर देना आवश्यक है, भले ही वे अपर्याप्त हों। यदि आप परियोजना के दिशानिर्देशों पर दोबारा विचार करने के बारे में गंभीर हैं, तो सबसे लाभकारी संशोधनों पर विचार करें और उन्हें धीरे-धीरे परियोजना में शामिल करें।

कवर छवि क्रेडिट: Pexels से लुइस गोम्स द्वारा फोटो