JS-टीम: कैसे कोड स्टाइल नसों और डेडलाइन को बचाता है

क्यों code style "सुंदर दिखने" के बारे में नहीं, बल्कि "पागल न होने" के बारे में है?

कल्पना करें: आप एक सहकर्मी का कोड खोलते हैं, और वहाँ var और let का मिश्रण है, इंडेंटेशन बेतरतीब (कभी 2 स्पेस, कभी 4, कभी टैब), और सेमीकोलन कभी हैं, कभी नहीं। परिचित लगता है? यदि हाँ, तो आप जानते हैं कि ऐसा कोड कितनी जल्दी काम को नरक बना सकता है। अकेले आप अभी भी समझ सकते हैं, लेकिन जब प्रोजेक्ट में 5-10 JavaScript डेवलपर हों, तो एक समान code style की कमी उत्पादकता को खत्म कर देती है।

Code style (कोड शैली) और कन्वेंशन लिंटर की "इच्छाएँ" नहीं हैं। यह वह भाषा है जिसमें आपकी टीम संवाद करती है। जब हर कोई अपने तरीके से लिखता है, तो कोड "बाबेल का टॉवर" बन जाता है। और जब आप नियमों पर सहमत होते हैं, तो आप code review में स्पेस को लेकर बहस में घंटे बर्बाद करना बंद कर देते हैं और आर्किटेक्चर पर चर्चा करना शुरू करते हैं।

इस लेख में, मैं दिखाऊंगा कि टीम में JavaScript के लिए कोड मानकों को कैसे लागू करें, वास्तविक उदाहरण दूंगा, और बताऊंगा कि कौन से उपकरण वास्तव में डेडलाइन बचाते हैं। चलिए शुरू करते हैं!

JavaScript में कन्वेंशन क्यों बुनियादी हैं?

JavaScript एक बेहद लचीली भाषा है। आप एक ही फंक्शन को दर्जनों तरीकों से लिख सकते हैं। और यह तब तक अच्छा है जब तक आप अकेले काम करते हैं। लेकिन टीम में, लचीलापन अराजकता में बदल जाता है। यहाँ तीन कारण हैं कि js कन्वेंशन क्यों अनिवार्य हैं:

\n
• प्रोजेक्ट में प्रवेश की गति। एक नया डेवलपर कोड खोलता है और तुरंत तर्क समझ जाता है, क्योंकि सब कुछ "हमारे यहाँ प्रचलित" है। यह अनुमान लगाने की ज़रूरत नहीं है कि _this का क्या मतलब है या वेरिएबल का नाम x1 क्यों है।
\n
• कम बग। एक समान JavaScript कोड शैली मूर्खतापूर्ण गलतियों की संभावना को कम करती है: एक जगह भूला हुआ सेमीकोलन, दूसरी जगह अतिरिक्त कॉमा - लिंटर पकड़ लेगा।
\n
• Code review लड़ाई नहीं रह जाता। "यहाँ टैब चाहिए!" के बजाय आप चर्चा करते हैं "क्या हम इस लॉजिक को एक अलग हुक में निकाल सकते हैं?"।
\n

वैसे, Google के एक अध्ययन से पता चला है: एक समान code style वाली टीमें रिव्यू पर 30% कम समय बिताती हैं। यह आंकड़ा प्रभावशाली है, है ना?

5 शीर्ष JavaScript कन्वेंशन जो आपकी टीम को बचाएंगे

मैं आपको सौ नियमों से बोर नहीं करूंगा। मैं पाँच बुनियादी नियमों पर प्रकाश डालूंगा जो 90% समस्याओं को कवर करते हैं। बाकी को अपने अनुसार सेट करें।

1. नामकरण: स्पष्ट बोलें

खराब वेरिएबल नाम बुराई की जड़ है। JavaScript में नामकरण कन्वेंशन लगभग तय हैं:

\n
• वेरिएबल और फंक्शन के लिए camelCase: userName, getUserData।
\n
• क्लास और React कम्पोनेंट के लिए PascalCase: UserProfile, ApiService।
\n
• रनटाइम से पहले ज्ञात कॉन्स्टेंट के लिए UPPER_SNAKE_CASE: MAX_RETRY_COUNT।
\n

खराब और अच्छे का उदाहरण:

// खराब: कुछ स्पष्ट नहीं\nlet d = new Date();\nlet fn = () => { ... };\n\n// अच्छा: किताब की तरह पढ़ा जा सकता है\nlet currentDate = new Date();\nlet fetchUserData = () => { ... };

2. सेमीकोलन: लगाएं या नहीं?

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

// सेमीकोलन के बिना - संभावित त्रुटि\nlet a = 1\n[1, 2, 3].forEach(console.log) // त्रुटि! इंटरप्रेटर सोचता है कि यह लाइन की निरंतरता है\n\n// सेमीकोलन के साथ - सब ठीक\nlet a = 1;\n[1, 2, 3].forEach(console.log);

3. एरो फंक्शन बनाम function

यहाँ JavaScript कन्वेंशन सलाह देते हैं: कॉलबैक और छोटे फंक्शन के लिए एरो फंक्शन का उपयोग करें, और शीर्ष स्तर की घोषणाओं के लिए function का (hoisting के कारण)।

// अच्छा: कॉलबैक के लिए एरो\nconst numbers = [1, 2, 3];\nconst doubled = numbers.map(n => n * 2);\n\n// अच्छा: घोषणा के लिए function\nfunction calculateTotal(price, tax) {\n    return price + pr