कास्ट बनाम - क्या उपयोग करने के लिए?

नमस्कार, हेब्र! मैं आपको दान अब्रामोव के लेख "ऑन लेट बनाम कॉन्स्ट" का अनुवाद प्रस्तुत करता हूं।

मेरी पिछली पोस्ट में यह पैराग्राफ है:

let vs const vs var : आम तौर पर, आप सभी की जरूरत है। यदि आपको किसी चर को फिर से लिखने से रोकने की आवश्यकता है, तो आप कास्ट का उपयोग कर सकते हैं। (कुछ इस बारे में बहुत पांडित्य हैं और केवल एक चर असाइनमेंट होने पर कास्ट का उपयोग करना पसंद करते हैं)।

यह बयान ट्विटर पर बहुत विवादास्पद निकला, और Reddit'e ने तुरंत इस बारे में गर्म चर्चा शुरू की। ऐसा लगता है कि सबसे लोकप्रिय राय (या कम से कम मौखिक रूप से बहुमत से व्यक्त की गई है) यह है कि आपको हमेशा कॉन्स्ट का उपयोग करना चाहिए और केवल आवश्यक होने पर ही संदर्भित करना चाहिए , जो कि ESLint के पसंदीदा -कॉन्स्ट नियम द्वारा प्रदान किया जा सकता है।

इस पोस्ट में, मैं उन सभी पेशेवरों और विपक्षों की संक्षिप्त सूची दूंगा जो मुझे मिले और इस मामले पर अपनी व्यक्तिगत राय व्यक्त की।

कॉन्स्ट क्यों पसंद करते हैं

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

कॉन्स्ट पसंद क्यों नहीं करते

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

  const a = cond ? b : c 

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

मेरी राय

मुझे परवाह नहीं है।

मैं किसी भी नियम का उपयोग कर सकता हूं जो अन्य उपयोग करते हैं।

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

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

मूल लेख के लिए लिंक - चलो बनाम कास्ट ।