क्या "if (0 == मान) ..." अच्छे से अधिक नुकसान नहीं करता है? [बन्द है]


49

यह उन चीजों में से एक है जिसे मैं सबसे ज्यादा नफरत करता हूं जब मैं इसे किसी और के कोड में देखता हूं। मुझे पता है कि इसका क्या मतलब है और कुछ लोग इसे इस तरह से क्यों करते हैं ("क्या होगा अगर मैं गलती से इसके बजाय '=' डाल दूं?")। मेरे लिए यह बहुत पसंद है जब एक बच्चा सीढ़ियों से नीचे कदम रखता है और जोर से चिल्लाता है।

वैसे भी, यहाँ इसके खिलाफ मेरे तर्क हैं:

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

17
मैं इसके लिए बहुत परवाह नहीं करता, लेकिन यह पालतू जानवरों की मेरी व्यक्तिगत सूची से बहुत दूर है।
एडम क्रॉसलैंड

7
और प्रोग्रामर कभी-कभी डबल '=' याद करते हैं। यह एक आसान गलती है और एक जिसे अनदेखा करना बहुत आसान है।
संग

8
यह कैसे रचनात्मक नहीं है या एक वास्तविक प्रश्न नहीं है?
TheLQ

7
यह मेरी छोटी राय है इसलिए इसे बंद कर दिया गया है: लोग कैसे लिखना याद कर सकते हैं 0 == valueलेकिन लिखना याद नहीं है ==?? मेरा मतलब है कि अगर आप इसके बारे में सोच रहे हैं, तो इसे शुरू करने के लिए सही तरीके से क्यों न लिखें।
हेंनिबल लेक्टर

3
@ मंटू: संकलनकर्ताओं के अनुसार, बहुत सारी चीजें "सही" हैं, मुझे नहीं लगता कि यह बहुत अच्छा बेंचमार्क है।
हनीबल लेक्टर

जवाबों:


59

आह, हां, "योदा सशर्त" ("यदि शून्य मान है, तो इस कोड को निष्पादित करें जो आपको अवश्य करना चाहिए!")। मैं हमेशा किसी को भी इंगित करता हूं जो दावा करते हैं कि वे लिंट (1) जैसे उपकरणों पर "बेहतर" हैं। 70 के दशक के उत्तरार्ध से यह विशेष समस्या हल हो गई है। अधिकांश आधुनिक भाषाएं भी अभिव्यक्ति को संकलित नहीं करेंगी if(x = 10), क्योंकि वे एक बूलियन को असाइनमेंट के परिणाम के लिए मना करते हैं।

जैसा कि दूसरों ने कहा है, यह निश्चित रूप से एक समस्या नहीं है, लेकिन यह संज्ञानात्मक असंगति का एक सा उकसाता है।


32
"Yoda सशर्त" के लिए +1। मैं वास्तव में उस पर योग्य था। :)
बॉबी टेबल्स

3
जबकि आदेश ठीक है, मैं, तुलना पर आपत्ति सादा बूलियन कलाकारों के बजाय शून्य if(!value)
एसएफ।

1
तो आप एक सशर्त त्रुटि के अंदर असाइनमेंट पर विचार करते हैं?

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

3
क्या कोई कंपाइलर जानता है जो कंपाइल नहीं करेगा if (0 == x)?
क्रिस्टोफर Ives

56

यह अप्रिय है क्योंकि यह एक छोटा, लेकिन ध्यान देने योग्य मानसिक कर लगाता है।

लोग लगभग सभी प्रोग्रामिंग भाषाओं (और सबसे प्राकृतिक भाषाओं) में दाएं से बाएं पढ़ते हैं।

अगर मैं देखता हूं 123 == x, तो जिस तरह से मैं मानसिक रूप से इसे पार्स कर रहा हूं वह है:

  • 123- तो क्या? अधूरी जानकारी।
  • == - ठीक है, 123 123 है, इसे क्यों टेस्ट करें ...
  • x- ठीक है, इसलिए हम इस बारे में चिंतित हैं। केवल अब मेरे पास संदर्भ है।
  • पुनर्विचार करने के लिए वापस जाएं 123और एक्स की तुलना क्यों की जाती है।

जब मैं देखता हूं कि x == 123मानसिक पार्सिंग है:

  • x- संदर्भ प्रदान करता है, मुझे पता है कि हालत क्या है। मैं बाकी चीजों को नजरअंदाज करना चुन सकता हूं। पिछले प्रवाह के आधार पर मेरे पास एक अच्छा विचार है कि क्यों और क्या आना है (और अगर यह अलग है तो आश्चर्यचकित हो)।
  • == - मुझे ऐसा लगा।
  • 123 - हाँ।

व्यवधान छोटा है (एक सरल उदाहरण में), लेकिन मैं हमेशा इसे नोटिस करता हूं ।

यदि आप इस पर ध्यान आकर्षित करना चाहते हैं, तो पहले मूल्य डालना एक अच्छा विचार हो सकता है if (LAUNCH_NUKES == cmd)। आम तौर पर यह इरादा नहीं है।


5
ठीक ठीक। प्राकृतिक भाषाओं में स्थिरांक हमेशा एक ही कारण से आता है: यदि प्रकाश लाल है ...
मोजुबा

2
@mojuba सच है, यह लगभग सार्वभौमिक है। अजीब तरह से, कुछ प्राकृतिक भाषाएं हैं जहां विषय (OVS / OSV ऑर्डर) से पहले ऑब्जेक्ट आता है, लेकिन वे सभी अस्पष्ट हैं।
dbkk

1
दूसरी ओर, हममें से कुछ लोग चर से पहले प्रतीकों को पढ़ते हैं। वे और अधिक आंख को पकड़ने रहे हैं। इसलिए मैं बाहर =या उससे ==पहले 123या उसके बाहर पार्स करूंगा x, और कोड को अंग्रेजी में अनुवाद करने की जहमत भी नहीं उठाऊंगा।
इजाकाता

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

47

नुकसान पहुचने वाला? यह किसी भी तरह से काम करता है।

बुरा अभ्यास? डिबेटेबल, बेस्ट। यह सरल रक्षात्मक प्रोग्रामिंग है।

नींद खोने पर चिंता? नाह।


8
और जब मैं इसे पढ़ता हूं, तो मैं तुरंत कोड को समझता हूं जो मेरे लिए एक महत्वपूर्ण कारण है जो कोडिंग शैली पर बहस करता है। मैं पूरी तरह से सहमत हूं, नींद खोने के लायक नहीं है।
जेफ सिवर

17

यह मूल रूप से flaimbait है।

नहीं, यह अच्छे से अधिक नुकसान नहीं करता है। सरल।

ओर शब्द?

संकलक तर्क? एर्म, ईश, हो सकता है - आपको अपने आप से बचाने के लिए बहुत अधिक विश्वास न करें।

"आपको नहीं भूलना चाहिए" - अच्छी तरह से दुआ - निश्चित रूप से आप इस बीच नहीं थकेंगे कि मैं थक गया हूं, मैं पूरे दिन कोडिंग कर रहा हूं मुझे दो अलग-अलग भाषाओं का उपयोग करना पड़ा है और कभी-कभी, बस कभी-कभी, मानव होने के नाते मैं बनाता हूं एक गलती।

इस तरह के व्यवहार की बात यह है कि इसका रक्षात्मक, इसका नहीं है क्योंकि आप किसी भी अधिक से अधिक गलतियों की उम्मीद करते हैं क्योंकि आपके पास बीमा है क्योंकि आप दुर्घटना की उम्मीद करते हैं ... लेकिन अगर आप इसे कवर करने के लिए अच्छा करते हैं।

पढ़ने में कठिन? आप शिकायत कर रहे हैं कि एक सभ्य प्रोग्रामर के पास == हार्डवेयर्ड होना चाहिए (जो सभी प्रकार की खराब धारणाएं बनाता है) लेकिन यह कि स्वयं समान सभ्य प्रोग्रामर 0 == मूल्य नहीं पढ़ सकता है ??

कोई नुकसान नहीं, संभावित लाभ है, मूर्खतापूर्ण सवाल है, दूसरों को यह करना चाहिए अगर वे चाहते हैं और आगे बढ़ें।


6
मुझे लगता है कि 0 == मान उन लोगों के लिए अप्राकृतिक पढ़ता है जिन्होंने प्रोग्रामिंग का अध्ययन करने से पहले बीजगणित के तरीके का अध्ययन किया था।
मोजुबा

4
यह इस तरह की बात नहीं है - हाँ, आप सही कह रहे हैं कि यह सही नहीं है लेकिन समान रूप से हम जो भी प्रोग्रामर के रूप में लिखते हैं, उतना ही बड़ा लेख प्राकृतिक भाषा के रूप में बिल्कुल नहीं दिखता है और यह इस बात का है कि आप क्या व्याख्या करते हैं आप देखते हैं
मर्फ़

4
ब्रावो .. इस तथ्य का उल्लेख नहीं करने के लिए कि क्योंकि यह अस्वाभाविक रूप से पढ़ता है आप इसके लिए करीब ध्यान देने के इच्छुक हैं, इसलिए संभावित गलतियों को पकड़ते हैं।
mocj

7
@ मोकज - इसलिए, हमें यह सुनिश्चित करने के लिए सभी कोड को लागू करना चाहिए कि हमारे कोड को पढ़ने वाले लोगों को वास्तव में हमारे कोड को पढ़ने की आवश्यकता है ?
काज़ ड्रैगन

6
@ मोकज - मैं इसकी सराहना करता हूं, लेकिन आपका तर्क यह था कि "ब्रेन स्ट्रेचर" जैसा कि आप पढ़ रहे हैं योदा की स्थिति अच्छी है। मैं सवाल पूछ रहा हूँ कि, अगर ऐसा है, तो क्या हमें सभी कोड लिखने का लक्ष्य रखना चाहिए ताकि हम "ब्रेन स्टुटर्स" का कारण बनें? असली सवाल।
काज ड्रैगन

11

मैं इसे नुकसान नहीं कहूंगा, लेकिन यह अप्रिय है। तो नहीं मैं यह नहीं कहूंगा कि यह करता है।


10

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


5
यह सवाल का बिंदु नहीं है, बिंदु "क्या यह हानिकारक है" - और यह नहीं है। सबसे खराब पर एक बहुत ही मामूली जलन, लेकिन हानिकारक नहीं।
मर्फ़

1
गतिशील भाषाओं में - बिल्कुल, आप एक प्रतीक को गलत कर सकते हैं और अपना समय बाद में अपने बग के स्रोत की तलाश कर सकते हैं
mojuba

3
पूरे सम्मान के साथ, जब आपने एक देर रात (या दो) बिताए हैं और स्रोत (सी ++ कोड में) == के बजाय एक = है, तो यह कुछ वजन ले जाएगा।
देवसोलो

2
@DevSolo: मुझे लगता है कि वास्तव में आपके करियर में एक या दो बार होना चाहिए, लेकिन इससे ज्यादा नहीं
mojuba

9

कुछ लोग इसका उपयोग यह स्पष्ट करने के लिए करते हैं कि एक सशर्त क्या कर रहा है। उदाहरण के लिए:

रास्ता 1:

FILE *fp;

fp = fopen("foo.txt", "w+");
if (fp == NULL) {

रास्ता 2:

FILE *fp;

if (NULL == (fp = fopen("foo.txt", "w+"))) {

कुछ लोगों को लगता है कि दूसरा उदाहरण अधिक संक्षिप्त है, या तर्कों को उलटने से परीक्षण से पहले एक परीक्षण (सशर्त) के बिंदु को दिखाता है।

सभी वास्तविकताओं में, मैं वास्तव में किसी भी तरह से बुरा नहीं मानता। मेरे पास शैली के बारे में मेरे पालतू पशु हैं और सबसे बड़ी एक असंगति है। तो, इसे उसी तरह से करें, लगातार और मुझे आपका कोड पढ़ने में कोई आपत्ति नहीं होगी।

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


4
दूसरा उदाहरण मुझे "हुह?" पहला बहुत अधिक पठनीय है। महान उदाहरण है। :)
मातेन उल्हाक

6

मेरे लिए, यह सरल कंडीशनिंग है। जैसा कि किसी ने सीखा (90 के दशक में) सी और सी ++, मैं इसके आदी हो गया और अभी भी इसका उपयोग करता हूं, भले ही कारणों को सबक दिया गया हो।

एक बार जब आप "स्थिर" के लिए बाईं ओर देखने के लिए "वातानुकूलित" होते हैं, तो यह दूसरी प्रकृति बन जाती है।

मैं भी इसे केवल तुल्यता (या नकारात्मक समतुल्यता) के लिए उपयोग करता हूं, इससे अधिक / कम के लिए नहीं।

मैं पूरी तरह से डब्ल्यू / @ वोनको के जवाब से सहमत हूं।


5

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

उदाहरण के लिए, मैंने जो कुछ एकल साइन-ऑन के साथ काम किया था, एक ऐसी स्थिति थी जहाँ आप दो समवर्ती सत्र कर सकते थे यदि एक निश्चित प्रकार की त्रुटि हुई थी और एक निश्चित तरीके से पुनर्प्राप्त की गई थी, तो मुझे इसके लिए एक हैंडलर जोड़ना होगा जो अगर देखा गया था तो कुछ इस तरह:

if (2 <= application.httpcontext.current.session["thenameofmysessiontoken"].items.count())

इस उदाहरण में माना जाता है कि ऐसा करने के अन्य तरीके हैं, लेकिन यह एक ऐसा मामला होगा जहां संख्या-पहला संस्करण संभवतः अधिक पठनीय है।


2
मुझे लगता है कि यहां कीवर्ड "ऐसा करने के अन्य तरीके" हैं;)
मोजुबा

इस मामले में हाँ, लेकिन कुछ मामलों में यह अभी भी सबसे पठनीय परिणाम है। मेरा एकमात्र बिंदु यह है कि भाषा या विचार व्यवहार और टाइप-ओ के अलावा अन्य करने के लिए कुछ वैध कारण हैं
बिल

सच कहूं तो, मुझे <= और> = के लिए योदा की शर्तों के साथ कठिनाइयाँ हैं। == साइन एक अलग मामला है, क्योंकि मेरे सिर में मैं सिर्फ प्रतीकों को इधर-उधर कर सकता हूं, लेकिन आपके मामले में मुझे यह याद रखना होगा कि गिनती () 2 से अधिक या बराबर होनी चाहिए, और इससे व्युत्पन्न होने के लिए कष्टप्रद है। एक छोटा-या-बराबर चिह्न।
एलेक्स

3

और फिर भी त्रुटियां होती हैं। और कभी-कभी आप एक लूप ऑपरेटर में एक असाइनमेंट चाहते हैं जहां आप अन्यथा समानता की जांच कर सकते हैं, या कम से कम इसका उपयोग करने के लिए मानक अभ्यास है।

मैं इसके साथ कुछ हद तक पकड़ता हूं। मेरे द्वारा पालन की गई सलाह (संभवतः कोड कम्प्लीट से) यह है कि तुलना में बाईं ओर कम मूल्य क्या होना चाहिए। मैं एक सहकर्मी के साथ इस बारे में चर्चा कर रहा था और उसने सोचा कि यह पागल है, लेकिन मुझे इसकी बहुत आदत है।

तो मैं कहूंगा:

if ( 0 <= value )

लेकिन मैं यह भी कहूंगा:

if ( value <= 100 )

समानता मैं बाईं ओर चर के साथ जाँच करने के लिए करते हैं, यह सिर्फ अधिक पठनीय है।


1
मुझे if(y > x)हर समय उपयोग करने की आदत है । जब तक yएक स्थिर है।
मतीन उल्हाक

मैं इसे इस तरह से करता था, लेकिन एक बार जब मुझे बाईं ओर सबसे कम मूल्य होने का विचार आया तो मैंने पाया कि मेरा कोड एक नज़र में बहुत अधिक पठनीय है।
glenatron
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.