JSLint उम्मीद '===' और इसके बजाय '==' देखा

Question

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

क्या वाकई इससे कोई मतलब है? मैं बहुत सारे उदाहरण देख सकता हूं कि आप प्रकार की तुलना नहीं करना चाहते हैं, और मुझे चिंता है कि यह वास्तव में समस्याएं पैदा कर सकता है।

"उम्मीद" शब्द का अर्थ यह होगा कि यह हर समय किया जाना चाहिए ..... यही मेरे लिए कोई मतलब नहीं है।

Comments

मैं JSLint के साथ भी इसमें भाग गया। मैंने == से === तक एक अपडेट किया और इसने वास्तव में पहले से काम कर रहे कोड को तोड़ दिया।

— kemiller2002

यदि आपके कोड में 100 से अधिक लाइनें हैं, तो यह jslint पास नहीं करेगा, वास्तव में, यह असंभव है।

"ब्रोक" बहुत मजबूत शब्द है। इसने आपके कोड के अर्थ को बदल दिया। यदि आप एक myVar == nullजाँच कर रहे थे , हाँ, बड़े बदलाव। ; ^) क्रॉकफोर्ड का तर्क है कि इसने कोड के अर्थ को अधिक सटीक बना दिया है, और यह तर्क करना कठिन है।

— रफिन

Answer 1

IMO, आँख बंद करके ===, यह समझने की कोशिश किए बिना कि किस प्रकार से रूपांतरण कार्य बहुत मायने नहीं रखता है।

इक्वाल्स ऑपरेटर के बारे में प्राथमिक डर== यह है कि तुलना के प्रकारों के आधार पर तुलनात्मक नियम ऑपरेटर को गैर-परिवर्तनशील बना सकते हैं, उदाहरण के लिए, यदि:

A == B AND
B == C

वास्तव में इसकी गारंटी नहीं है:

A == C

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

'0' == 0;   // true
 0  == '';  // true
'0' == '';  // false

===जब आप एक ही प्रकार के मूल्यों की तुलना करते हैं तो स्ट्रिक्ट इक्वलस ऑपरेटर वास्तव में आवश्यक नहीं है, सबसे सामान्य उदाहरण:

if (typeof foo == "function") {
  //..
}

हम typeofऑपरेटर के परिणाम की तुलना करते हैं , जो हमेशा एक स्ट्रिंग है , एक स्ट्रिंग शाब्दिक के साथ ...

या जब आप प्रकार के नियम जानते हैं, उदाहरण के लिए, जांचें कि क्या कुछ है nullया undefinedकुछ है:

if (foo == null) {
  // foo is null or undefined
}

// Vs. the following non-sense version:

if (foo === null || typeof foo === "undefined") {
  // foo is null or undefined
}

Comments

मुझे JSLint के इस नियम से नफरत है। मुझे लगता है कि असली समस्या यह है कि लोगों को उन तरीकों से ऑपरेटरों का उपयोग नहीं करना चाहिए जो उन्हें समझ में नहीं आते हैं (विडंबना यह है कि ये अक्सर एक ही तरह के लोग होते हैं जो नेत्रहीन रूप से '===' को '==' से बदल देंगे)। निश्चित रूप से, कुछ सामान्य मामले हैं जो विभिन्न तारों के साथ संख्या 0 की तुलना करते समय उत्पन्न होते हैं, लेकिन यदि आप असंबंधित डेटा की तुलना कर रहे हैं जैसे 0 == 'यह एक स्ट्रिंग है' - आपके कोड में संभवतः डबल बराबर की तुलना में बड़ी समस्याएं हैं! यदि आप सुनिश्चित करते हैं कि आप किस प्रकार के साथ काम कर रहे हैं और आप जानते हैं कि वे वास्तव में कैसे == के साथ बातचीत करते हैं, तो मुझे लगता है कि आपको इसका उपयोग करना चाहिए।

— जॉन

@Jon ===ऑपरेटर की बात कोड स्पष्टता है। उपयोग करने के लिए कोई उचित स्थिति ==नहीं है क्योंकि यह पहचान ऑपरेटर के रूप में कभी भी स्पष्ट और समझ में नहीं आएगा। यह नहीं है कि आप ऑपरेटरों को समझते हैं या नहीं, यह एक का उपयोग करने के बारे में है जो आपके कोड को लगभग बिना किसी खर्च के आसानी से पठनीय बनाता है। केवल डेवलपर्स जो पहचान ऑपरेटर के खिलाफ बहस कर रहे हैं वे एकल डेवलपर्स और ऐसे लोग हैं जो टीमों में काम नहीं करते हैं। परिभाषा के अनुसार, जिन लोगों के कोड की समीक्षा पर्याप्त आंखों से नहीं की जाती है।

— अल्टरनेटेक्स

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

— जॉन

आवश्यक परीक्षण करने के लिए == का उपयोग करते समय वास्तव में समय होता है। अगर foo.toString () एक प्रेडिक्टेबल अंदाज में परफॉर्म करेगा और उस आउटपुट के खिलाफ प्लेन स्ट्रिंग को टेस्ट करने की जरूरत है तो foo == stringToTest लिखना foo.toString () === stringToTest की तुलना में काफी साफ है।

— क्रिस्पेन स्मिथ

@Alternatex अगर बात स्पष्टता की थी तो उन्हें इसे TRIPLE के बराबर नहीं बनाना चाहिए था! कोई भी शुरुआत करने वाला इसे नहीं समझता। अन्य भाषाओं से कम से कम डबल बराबरी ज्ञात है। साथ ही, there is no reasonable situationघोर कुप्रबंधन है। (देशी) जावास्क्रिप्ट प्रकारों के बारे में सोचें Numberऔर String। उनके अस्तित्व ने साबित किया कि जावास्क्रिप्ट लेखकों के लिए कुछ उपयोग मामलों को ध्यान में रखा गया था ==। क्या आप वास्तव में सोचते हैं कि new String('hi') === 'hi'मूल्यांकन करना falseबहुत स्पष्ट है? कृपया एक कोड स्निपेट लिखें जो 'hi'स्ट्रिंग और स्ट्रिंग दोनों को स्वीकार करने के खिलाफ आपके फ़ंक्शन तर्क का परीक्षण करता है और मुझे बताएं कि स्पष्ट है।

— स्टिजन डे विट

Answer 2

JSLint, जावास्क्रिप्ट सिंटैक्स की तुलना में स्वाभाविक रूप से अधिक रक्षात्मक है।

JSLint प्रलेखन से:

==और !=ऑपरेटरों की तुलना से पहले प्रकार बलात्कार करते हैं। यह बुरा है क्योंकि यह ' \t\r\n' == 0सच होने का कारण बनता है। यह प्रकार की त्रुटियों को मुखौटा कर सकता है।

निम्नलिखित में से किसी भी मान की तुलना करते समय, ===या !==ऑपरेटर (जो टाइप कॉर्शन नहीं करते हैं) का उपयोग करें:0 '' undefined null false true

यदि आप केवल इस बात का ध्यान रखते हैं कि कोई मूल्य सत्य या मिथ्या है , तो संक्षिप्त रूप का उपयोग करें। के बजाय

(foo != 0)

सिर्फ कहे

(foo)

और के बजाय

(foo == 0)

कहते हैं

(!foo)

===और !==ऑपरेटरों पसंद किया जाता है।

Comments

मुझे जेएसएलआईएनटी के लोगों को कुछ बहुत ऊँचे आइवरी टॉवर में काम करना है, जिससे वे कभी बाहर नहीं निकलते हैं। जावास्क्रिप्ट को ऑपरेटर के साथ उपयोग करने के लिए डिज़ाइन किया गया था ==। यह ===एक विशेष मामला है ... जेएसएलआईएनटी यह कोशिश करता है कि ऐसा लगता है कि उपयोग ==करना किसी तरह गलत होगा ... हालांकि, यह प्रयास करें var x = 4, y = new Number(4); if (x == y) {alert('Javascript depends on == just embrace it!');}:। आदिम प्रकारों में संबंधित वर्ग होते हैं जो उनके लिए विकल्प ( Number, String) और जावास्क्रिप्ट ==इन प्राकृतिक की तुलना करने के लिए ऑपरेटर पर निर्भर करते हैं।

— स्टिजन डे विट

Answer 3

ध्यान रखें कि JSLint एक व्यक्ति के विचार को लागू करता है कि जावास्क्रिप्ट कितना अच्छा होना चाहिए। आपके द्वारा सुझाए गए परिवर्तनों को लागू करते समय आपको अभी भी सामान्य ज्ञान का उपयोग करना होगा।

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

Comments

प्लस यह एक प्रोग्रामर के रूप में संदर्भ-स्मार्ट नहीं हो सकता है। यह सिर्फ इस आधार पर काम कर रहा है कि अधिकांश उपयोगकर्ता सिस्टम में निहित ऑटो टाइप रूपांतरण द्वारा फंस जाते हैं (जैसे कि हिंसा - "मेरी मदद की जा रही है!")

— रुडू

Answer 4

ट्रिपल-बराबर डबल-बराबर करने के लिए अलग है क्योंकि यह जाँचने के अलावा कि क्या दोनों पक्ष समान मूल्य हैं, ट्रिपल-बराबर यह भी जाँचते हैं कि वे एक ही डेटा प्रकार हैं।

तो ("4" == 4)सत्य है, जबकि ("4" === 4)असत्य है।

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

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

लेकिन JSLint के बारे में अच्छी बात यह है कि यह सिर्फ एक गाइड है। जैसा कि वे साइट पर कहते हैं, यह आपकी भावनाओं को चोट पहुंचाएगा, भले ही आप एक बहुत अच्छे जावास्क्रिप्ट प्रोग्रामर हों। लेकिन आपको इसकी सलाह मानने के लिए बाध्य नहीं होना चाहिए। यदि आपने पढ़ा है कि इसे क्या कहना है और आप इसे समझते हैं, लेकिन आपको यकीन है कि आपका कोड टूटने वाला नहीं है, तो कुछ भी बदलने के लिए आपकी कोई मजबूरी नहीं है।

यदि आप चेतावनियों के साथ बमबारी नहीं करना चाहते हैं, तो आप JSLint को चेक की श्रेणियों को अनदेखा करने के लिए भी कह सकते हैं, जिसके बारे में आप कुछ नहीं करने जा रहे हैं।

Comments

मैंने "क्या ===" नहीं पूछा है, इसलिए मुझे यकीन नहीं है कि आपने इसका जवाब क्यों दिया।

— महानगर

@ मेट्रोपोलिस: यदि कोई अन्य कारण नहीं है, तो पृष्ठभूमि के रूप में मामले में किसी और ने जवाब पढ़ा जो नहीं जानता था। मैंने उस के बाद के पैराग्राफ में आपके प्रश्न का उत्तर देने का प्रयास किया।

— स्पडली

अतिरिक्त और उपयोगी जानकारी के लिए @Spudley + 1

— बेन जूनियर

हाँ, यह 10-100 गुना तेज है: जेस्पर स्पीड टेस्ट

— vladkras

Answer 5

Http://javascript.crockford.com/code.html का एक उद्धरण :

=== और! == संचालक।

=== और! == ऑपरेटरों का उपयोग करना लगभग हमेशा बेहतर होता है। == और! = ऑपरेटर प्रकार की ज़बरदस्ती करते हैं। विशेष रूप से, गलत मूल्यों के खिलाफ तुलना करने के लिए == का उपयोग न करें।

JSLint बहुत सख्त है, उनके 'webjslint.js' भी अपना सत्यापन नहीं करते हैं।

Comments

अच्छा स्पष्टीकरण। यह सच है, webjslint.jsमान्य नहीं करने के बारे में - हालाँकि मैं अभी जिन त्रुटियों को देख रहा हूँ उनमें से अधिकांश का रिक्ति के साथ क्या करना है। स्पष्ट रूप से, किसी को JSLint का उपयोग करके जावास्क्रिप्ट की समीक्षा करते समय सामान्य ज्ञान और उचित निर्णय का उपयोग करना चाहिए।

— hotshot309

शब्द का उपयोग alwaysस्वतः इस उद्धरण को ज्ञान के रूप में अयोग्य घोषित करता है। स्मार्ट प्रोग्रामर हठधर्मिता नहीं कर रहे हैं। वे दी गई स्थिति में सबसे अच्छा उपयोग करते हैं। और वे भाषा के बहुत मूल में निर्मित किसी भी उपकरण का स्वागत करते हैं और उसे गले लगाते हैं, न कि इसे केवल एक के साथ खारिज करते हैं just never touch it। नीचे पंक्ति: मेरा कोड कम है (और केवल एक =चरित्र को बचाने से नहीं ), इस प्रकार मेरी साइट कम बैंडविड्थ लागत पर तेजी से लोड होती है, इस प्रकार मेरा उपयोगकर्ता बेहतर सेवा करता है।

— स्टिजन डे विट

Answer 6

यदि आप मिथ्यात्व के लिए परीक्षण करना चाहते हैं। JSLint अनुमति नहीं देता है

if (foo == null)

लेकिन अनुमति देता है

if (!foo)

Comments

उपयोग करें ===, जो JSLint अनुशंसा करता है।

— clickbait

@ नारवागेम यह समाधान पूरी तरह से स्वीकार्य है।

यह उत्तर अच्छा नहीं है। बात यह है कि इन दोनों का मतलब कुछ और है। foo == nullअशक्त या अपरिभाषित के लिए जाँच। !fooअशक्त, अपरिभाषित, 0 और खाली स्ट्रिंग के लिए चेक।

— मार्कोस

@ मार्कोस यह उत्तर JSLint को खुश करने और अपने कोड लॉजिक को अक्षुण्ण बनाए रखने के लिए एक उपयोगी विकल्प होने के लिए है, न कि एक सटीक समकक्ष होने के लिए। यही कारण है कि मैंने उत्तर दिया "अगर झूठ के लिए जाँच कर रहा है"

— nano2nd

Answer 7

इस सवाल को समझाने में मदद करने के लिए और यह भी बताएं कि क्यों नेटबाइन्स (से) 7.3 ने इस चेतावनी को दिखाना शुरू कर दिया है यह नेटबींस बग ट्रैकर पर प्रतिक्रिया से एक उद्धरण है जब किसी ने इसे बग के रूप में रिपोर्ट किया:

जावास्क्रिप्ट में == के बजाय === का उपयोग करना अच्छा है।

तुलना करने से पहले == और = = ऑपरेटर प्रकार की ज़बरदस्ती करते हैं। यह बुरा है क्योंकि यह 't \ r \ n' == 0 को सत्य बनाता है। यह प्रकार की त्रुटियों को मुखौटा कर सकता है। JSLint मज़बूती से यह निर्धारित नहीं कर सकता है कि == का उपयोग सही ढंग से किया जा रहा है, इसलिए इसका उपयोग नहीं करना सबसे अच्छा है == और! = बिल्कुल और हमेशा अधिक विश्वसनीय === और =! = = के बजाय ऑपरेटरों का उपयोग करें।

संदर्भ

Comments

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

— omikes

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

— omikes

@oMiKeY हाँ मैं देख रहा हूँ कि आप क्या मतलब है, वे और अधिक यथार्थवादी उदाहरण दे सकते हैं!

— ईएम-क्रिएशंस

Answer 8

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

Comments

लेकिन "अपेक्षित" शब्द का उपयोग क्यों किया जाता है? यह ऐसा लगता है जैसे आपको हमेशा ऐसा करना चाहिए।

— महानगर

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

— रशियो

सवाल था "क्या वाकई इसका कोई मतलब है?"। उस सवाल को देखते हुए, हाँ, यह करता है। इसके अलावा, यह पांच साल पहले था । यीशु।

— रशियो