== सच में एक बड़ा सौदा करें?

Question

मेरा एक सहकर्मी है जो लगातार लिखता है:

if (someBool == true)

यह मुझे दीवार उठाता है! क्या मुझे इसका एक बड़ा सौदा करना चाहिए या इसे छोड़ देना चाहिए?

Comments

मैं स्पष्ट if (some_flag == true)लेकिन निहित if (is_something)या पसंद करता हूं if (has_something)। चर नामों पर ध्यान दें।

— fredoverflow

अपने सहयोगी को याद दिलाएं कि किस प्रकार का someBool == trueबूलियन है, इसलिए उसी तर्क से यह होना चाहिए if ((someBool == true) == true)।

— माइक सेमोर

@GSto: मुझे लगता है कि आप इसे जानते हैं, लेकिन PHP में आप एक बूल को कुछ भी "कास्ट" कर सकते हैं और वास्तव में उपयोगी हो सकते हैं।

— zneak

@zneak या आप स्पष्ट और उपयोग किया जा सकता है $var = (bool) some_expression। और ज्यादातर मामलों में, यह भी मायने नहीं रखेगा क्योंकि पीएचपी गतिशील रूप से आवश्यक रूपांतरण करेगा।

— waiwai933

अगर आपने गलती से टाइप किया है == [हां मैं मजाक कर रहा हूं!]

— स्टीवन ए। लोवे

Answer 1

यह केवल अनावश्यक कोड है, न कि जीवन या मृत्यु। हालाँकि....

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

if(IsSomeCondition)

या

if(hasCondition)

या

if(somethingExists)

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

Comments

यह मेरे लिए सबसे सच है। इसकी सभी स्पष्टता और नामकरण की कला के बारे में, मूल वाक्यविन्यास उतना बुरा नहीं है लेकिन बेहतर कोड के लिए यह सही रास्ता है।

— TJB

मुझे इससे हराएं! उपयुक्त नामकरण के बिना, अधिक सुसंगत तुल्यता का कोई मतलब नहीं है।

— ट्रॉय हंट

मुझे someBool == trueस्पष्टता के लिए कई बार विरासत कोड का उपयोग करना पड़ा है । लेकिन अगर मैं स्क्रैच से लिखता हूं तो मैं चर का नाम अपने अनुसार if (isSomething)

— रखता हूं

मैं सहमत हूँ, नामकरण भले ही इसे हल करेगा, नाम था SomeBool, इसका मतलब कुछ भी हो सकता है और किसी भी प्रकार का हो सकता है (शायद एक सरणी में बूलियन की मात्रा के बराबर पूर्णांक?)। बूलियंस को किसी प्रकार की अस्तित्व क्रिया की आवश्यकता होती है, या वे हमेशा अपने दम पर पढ़ना मुश्किल होंगे।

— मॉर्गन हेरलॉकर

मैं सहमत हूं, यह पठनीयता के बारे में है। यदि चर अच्छे से नामांकित हैं, तो आपको इसकी आवश्यकता नहीं है। यदि अभिव्यक्ति इसके साथ बेहतर ढंग से पढ़ती है, तो मैं "== सच" के लिए जाऊंगा, यह भी संगत है यदि आप (= (बदसूरत) "" के बजाय "== झूठा" का उपयोग करते हैं)

— रॉनी ब्रेंडल

Answer 2

जब मैं देखता हूं someBool == true, तो मैं मदद नहीं कर सकता, लेकिन ऐसा महसूस करता हूं कि प्रोग्रामर ने मूल्यांकन के विचार को आंतरिक नहीं किया है, जो एक बहुत ही मौलिक कमी है।

हालाँकि, मेरा दृष्टिकोण तिरछा है क्योंकि मैंने कॉलेज में बच्चों को प्रोग्रामिंग सिखाने के लिए कई गर्मियों में बिताए हैं, जो अक्सर इस तरह के भाव लिखते थे क्योंकि वे वास्तव में अभिव्यक्ति का मूल्यांकन करने के मानसिक अभ्यास में महारत हासिल नहीं करते थे। एक बार जब उन्होंने अवधारणा को भुनाया, तो अतिरेक स्पष्ट हो गया।

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

Comments

मैं जल्दी से इस आदत को चाक नहीं करेगा। मैंने पेशेवर प्रोग्रामर के मुंह से कुछ सच्ची आश्चर्यजनक बातें सुनी हैं। आमतौर पर grokkers, में से एक ने उसके बाद शीघ्र ही बाद "यह कैसे किया कभी काम करते हैं?"

— डैश-टॉम-बैंग

मूल्यांकन के बारे में तहे दिल से सहमत हों। कभी-कभी मुझे आश्चर्य होता है कि "यह कहाँ रुकता है?" if ((((x == true) == true) == true)! = false) // और इसी तरह ...

— yawmark

कभी-कभी मैं लिखता हूं if (c == true) return true; else return false;, लेकिन 99% समय (1% वहां है क्योंकि मुझे कभी भी यकीन नहीं हो सकता है कि मैं कुछ याद नहीं करता) मैं तुरंत नोटिस करूंगा और पूरी चीज को बदल दूंगा return c। मुझे उम्मीद है कि अधिकांश सक्षम प्रोग्रामर को कुछ ऐसा ही करना चाहिए, अगर उन्होंने अपने करियर की शुरुआत में आदत विकसित की है। मुझे उम्मीद नहीं है कि एक wtf प्रतिक्रिया है।

— रेयान

अरे लड़का, सोचने की कला। मैं सचमुच पिछले सप्ताह हमारे कोडबेस में इस पार आया था। if (!someCondition) { someCondition = false; }मैंने अपने कोड में कुछ (एर, कई) अतिरेक के साथ-साथ कुछ असंभवताएं भी देखी हैं, लेकिन यह एक बहुत ही सरल था लेकिन अभी तक यह सोचने के लिए इतना उत्तेजित था कि किसी ने वास्तव में इसे लिखा था। कई बार, यहां तक ​​कि।

— एंथनी पेग्राम

बस ध्यान दें कि मैंने कुछ ऐसे मामले देखे हैं if(x) x=true;जो बेमानी नहीं थे, बल्कि इसके बराबर x=!!x;(x को

— 0/1

Answer 3

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

वैकल्पिक रूप से आप इस दृष्टिकोण की कोशिश कर सकते हैं:
आप: क्या आप बूलियंस के मूल्यांकन के लिए निम्नलिखित कोड सम्मेलन का उपयोग शुरू कर सकते हैं?

if (someBool==true)&&(true==true) {}

उन्हें: हम ऐसा क्यों करेंगे? उस कथन का दूसरा भाग निरर्थक है, यह हमेशा सत्य का मूल्यांकन करेगा।

आप: जॉर्ज द्वारा, आप सही हैं। मुझे मूर्ख। चलिए फिर सभी अतिरेक के बिना एक संस्करण के साथ चलते हैं। कैसा रहेगा?

if (someBool) {}

Comments

हाँ, सहमत हैं। यह मूर्खतापूर्ण है, लेकिन आप अपने झगड़े को उठा सकते हैं, और यह कोड वास्तव में वही कर रहा है जो आपके सहकर्मी को होगा। इसे एक गैर में उल्लेख करें - "क्या नरक आपके साथ गलत है?" तरह से, फिर इसे छोड़ दें। यद्यपि यदि वे "if (someBool! = True)" या "if! (SomeBool == true)" या अन्य ऐसे कॉन्फ़ोल्यूशन जैसे बकवास खींचने लगते हैं, तो हो सकता है कि कोई लड़ाई लड़ने लायक हो ...

— BlairHippo

कैसा है (someBool == false) किसी से भी बदतर (ifBool == true)?

— फाइनेंक

true=trueसंकलन नहीं है, आप नहीं कर सकते हैं आवंटित करने के लिए true;-)

— fredoverflow

मैं मिल करने के लिए उपयोग किया है if(somebool == false)या !=है, लेकिन हमेशा झूठे और सच के खिलाफ। मुझे यह बेमानी लगता है, लेकिन चूंकि कोडिंग मानक जोर देता if()है जो एक फ़ंक्शन की तरह दिखता है, जो कि परियों के बीच व्हाट्सएप कॉल करता है, मुझे इसे पढ़ने में मदद करता है। अपने दम पर, एक बूल एक बूल है, लेकिन if (somePointer)उड़ता नहीं है; मुझे पसंद है if (somePointer != NULL)क्योंकि एक सूचक एक बूल नहीं है।

— डैश-टॉम-बैंग

यह पठनीयता के बारे में है, न कि अतार्किक या (सूक्ष्म) -कुंडली के बारे में

— रोनी ब्रेंडेल

Answer 4

मुझे लगता है कि, अगर कुछ इतना तुच्छ है, तो आपके सहकर्मियों के साथ आपकी सबसे बड़ी समस्या है, आपको अपने आप को बहुत भाग्यशाली समझना चाहिए।

Comments

अच्छी तरह से, पूर्णता के लिए प्रयास करने के लिए अच्छा है, लेकिन निश्चित रूप से तलना करने के लिए बड़ी मछलियां हैं

— TJB

मुझे लगता है कि आप हर समस्या के बारे में यह कहते हैं जो चर्चा को गुण देती है।

— डेव वान डेन आईंडी

यह संभावित रूप से बहुत बड़ी समस्याओं का संकेत है। आपके गैरेज में छत पर एक छोटा सा भूरे रंग का दाग एक बड़ा सौदा नहीं लग सकता है , लेकिन इसका मतलब हो सकता है कि आपके पास पानी का एक बड़ा रिसाव हो।

— जोश

Answer 5

आपको इस बुरी आदत को जरूर रोकना चाहिए। धीरे ...

कोड को मोड़ते हुए दोहरे समान संकेतों को लिखना भूल जाना आसान है:

if (someBool = true)

उदाहरण के लिए C # में यह केवल चेतावनी देगा, त्रुटि नहीं। इसलिए जब तक आप चेतावनियाँ नहीं मानते, क्योंकि कोड चलेगा, चर को सही पर सेट करें और हमेशा स्थिति दर्ज करें।

Comments

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

— कैम

@Cam: बिंदु को याद कर रहे हैं आप। पीछे तर्क मैं सुझाव नहीं दे रहा हूँ।

— ग्यूफा

@Cam - वह एक वास्तविक दुनिया उदाहरण दे रहा है जब यह एक समस्या हो सकती है। मैं कहूंगा कि यह काफी प्रासंगिक है।

— चाओसपांडियन

@ गुफ़ा कैम बहुत सही है। यह ब्लॉक में == (anyType) का उपयोग बंद करने का एक कारण नहीं है।

— रॉनी ब्रेंडल

@ रोनी: नहीं, यह किसी भी प्रकार के साथ नहीं हो सकता है (जब तक कि भाषा वास्तव में किसी भी प्रकार की स्थिति के रूप में अनुमति नहीं देती है)। बयान if (answer = 42) {}केवल संकलन नहीं करता है क्योंकि अभिव्यक्ति एक बूल नहीं है।

— गुफ्फा

Answer 6

मैं आपसे सहमत हूँ, लेकिन मैं यहाँ शैतान के वकील की भूमिका निभाने जा रहा हूँ:

---

भाषा और चर के नाम के आधार पर, x == सत्य उचित है:

स्थिर टाइपिंग के साथ एक भाषा में निम्नलिखित स्थिति पर विचार करें और अभिन्न प्रकार के लिए जबरदस्ती टाइप करें:

if (actionsAllowed){
    //do actions, since they are allowed
    //...
}

कोड के इस भाग को पढ़ने वाला कोई व्यक्ति तुरंत यह महसूस नहीं कर सकता है कि कार्रवाई की गई है एक बूलियन चर है - यह एक पूर्णांक भी हो सकता है, अनुमत कार्यों की संख्या का प्रतिनिधित्व करता है। तो == सच जोड़कर, यह स्पष्ट हो जाता है कि x एक बूलियन है, और न कि एक पूर्णांक एक बूल के लिए मजबूर किया जा रहा है:

if (actionsAllowed == true){
    //do actions, since they are allowed
    //...
}

Comments

पठनीयता == गुडहिंग

— मुअदिद

अगर ((पठनीयता == GoodThing) == सच) ...

— JoelFan

bool .GoodThing = पठनीयता? सच: (कोडिंगस्टैंडर्ड्स? सच: (internalizationOfConcept; सच: गलत))?

— जॉन्च

इसलिए चर का नाम बदलें actionsAreAllowed।

— ग्रीम पेरो

लिखने से if (x) { ...आप पहले से ही यह दावा कर रहे हैं कि xएक बूलियन है या एक बूलियन के लिए परिवर्तनीय है। जिसे आप कहते हैं वह अप्रासंगिक है।

— डैनियल ईयरविकेर

Answer 7

अशक्त बूलों के बारे में क्या?

bool? MyFlag = null;

if (MyFlag == true)
    ;  

if (MyFlag)  // error, doesn't compile!
    ; 

Comments

if (MyFlag.Value)

— जॉन्क

सभी भाषाओं में अशक्त बूल नहीं हैं, और उनमें से कई जो आपके दूसरे निर्माण को स्वीकार करेंगे।

— zneak

@ जॉन्क: "अगर (MyFlag.Value)" वास्तव में आप ऐसा नहीं कर सकते जो आप चाहते हैं क्योंकि यह एक अपवाद फेंक सकता है यदि MyFlag शून्य है (जिसे आप MyFlag.HasValue की जाँच करके परीक्षण कर सकते हैं)।

— लुडोविक चबंत

इस नल bools साथ :) मेरी पालतू अपमान करना है

— जारोड डिक्सन

bool? isValid = null; if (isValid ?? false);

— स्कोलिमा

Answer 8

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

यह कहा जा रहा है, मैं == trueएक सशर्त बयान में जोड़ने के साथ कोई मुद्दा नहीं देखते हैं । तथ्य की बात के रूप में, मैं == falseनकारात्मक परिस्थितियों के लिए परीक्षण करते समय एक प्रमुख विस्मयादिबोधक बिंदु के विपरीत उपयोग करने की आदत में हूं । मुझे लगता है कि यह अधिक पठनीय है।

अगर कोई स्थापित सम्मेलन है, तो मैं कहता हूं कि जब तक बदलने का कारण नहीं है, इसका पालन करें। हालाँकि, यह वास्तव में एक बड़ा बदबू उठाने लायक नहीं है।

Comments

आपकी भाषा के आधार पर, someValue जरूरी नहीं कि वह सच के बराबर हो, भले ही वह सच का मूल्यांकन करता हो। उदाहरण के लिए, (9 == True)अजगर में असत्य का मूल्यांकन करता है और मैं C ++ में समान होगा।

— डैश-टॉम-बैंग

कोड क्षेत्र और प्रमुख अंडरस्कोर मुझे चेहरे पर लोगों को पंच करना चाहते हैं।

— एमजीऑवेन

Answer 9

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

Comments

यह कोई बुरी बात नहीं है। कोड जो वास्तविक पाठ की तरह पढ़ता है, निहित फू की तुलना में कहीं बेहतर है। पठनीयता के लिए उस आदत को बनाए रखें।

— रॉनी ब्रेंडल

Answer 10

मुझे "बूलियन पागलपन कोड" की याद दिलाएं, इसके जैसे

if(someBool == true)
   otherBool = false;
else
   otherBool = true

के बजाय:

 otherBool = !someBool

Comments

यह मज़ेदार है, मुझे एक ऐसी प्रणाली को बनाए रखना था, जो उन सभी पर लटकी हुई थी। इसने मुझे पागल कर दिया।

— टेजार्ट

Answer 11

व्यक्तिगत रूप से, मैं सी आधारित भाषाओं में "नहीं" कहने का तरीका पसंद नहीं करता। उस छोटे विस्मयबोधक चिह्न की अनदेखी करना बहुत आसान है।

इसलिए मैं इसे पूरी तरह से लिखता हूं:

if (someCondition == false) {

उस थोड़ी देर के लिए पढ़ने के बाद, मैं भी समरूपता चाहता हूं

if (someCondition == true) {

इसलिए इसे C के !बजाय उपयोग करने की एक कलाकृतियों पर विचार करें not।

Comments

सी ++ वास्तव में हैnot ऑपरेटर, और इतने सी करता है (एक बार आप मानक हेडर को शामिल <iso646.h>)। यदि आप इस शीर्ष लेख का उपयोग नहीं करना चाहते (या नहीं कर सकते हैं, या यदि आप जावा या सी # के साथ अटके हुए हैं), तो मैं सुझाव देता हूं कि विस्मयादिबोधक चिह्न के बाद एक स्थान रखें if (! condition):। यह इसे कुछ अधिक विशिष्ट बनाता है।

— कोनराड रुडोल्फ

मैं जावा करता हूं। notएक विकल्प नहीं है।

Answer 12

यह भाषा पर निर्भर करता है, लेकिन यह आमतौर पर एक बुरा विचार है ...

C में, ऐसा कभी न करें। ऐसी स्थिति खोजना बहुत आसान है जहां आप जो मान परीक्षण कर रहे हैं वह गलत (शून्य-शून्य) नहीं है, बल्कि "सही" के रूप में परिभाषित एकल मान के बराबर भी नहीं है।

रूबी में, यह केवल तभी करें जब आप पूरी तरह से निश्चित हों कि आप बूलियन को छोड़कर हर चीज पर विफल होना चाहते हैं।

C ++ और अन्य स्थिर भाषाओं में एक बूल प्रकार के साथ, यह बेमानी है, और जब आप गलत टाइप =करते हैं ==, या टिप्पणियों में उल्लिखित प्रचार त्रुटियों के बजाय प्रोग्रामिंग त्रुटियों को जन्म दे सकते हैं ।

Comments

दरअसल, उन भाषाओं में जहां असाइनमेंट ऑपरेटर एक मान देता है ... जैसे C ++ ... if (b == true) {केवल अनावश्यक नहीं है। यह थोड़ा जोखिम भरा भी है, क्योंकि आप गलती से सौंपे trueजा सकते हैं b।

— स्टीफन सी

यह C ++ में सिर्फ बेमानी नहीं है, यह खतरनाक है। यदि आप लिखते हैं if (b == true), और bएक बूल नहीं है, तो टाइप रूपांतरण गलत तरीके से चलते हैं। A boolएक अभिन्न प्रकार है जिसे आम तौर पर मान के साथ एक उपयुक्त अभिन्न प्रकार में पदोन्नत किया जाता है। यदि आप लिखते हैं, कहते हैं, int b(2); if (b == true)तो तुलना के प्रयोजनों के लिए मान 1 के साथ trueहो जाता है int, बजाय bटाइप में ज़ब्त होने के bool, जो सही परिणाम देगा।

— डेविड थॉर्नले

@DavidThornley, अपने संकलक में चेतावनी को चालू करें। चेतावनियों को त्रुटियों के रूप में मानने से बचने के बजाय बेहतर रक्षात्मक प्रोग्रामिंग तकनीक है ==।

— अब्येक Ab

Answer 13

आपको लगता है कि बुरा है? कैसा रहेगा:

if(someCondition) {
  return true;
} else {
  return false;
}

Comments

लड़का मैंने इसे कितनी बार देखा है। यह ReSharper जैसे टूल के लिए एक अच्छा केस बनाता है।

— जॉब

हां - यदि आप क्लोड किराए पर लेते हैं, तो ReSharper खरीदें।

— कर्क ब्रॉडहर्स्ट

Answer 14

मैं पसंद करता हूं

if (bVal)

या

if (!bVal)

भी, लेकिन मुझे डर है कि इसे लाने से लोग नाराज हो जाएंगे, इसलिए मेरी सलाह है कि इसे भूल जाओ। माफ़ करना!

Comments

वह सब के प्यार के लिए पवित्र है, जब तक यह है के रूप में है नहीं if (!bNotVal) या if (bNotVal)यहां तक कि पहली जगह में। नामों में ऊग नेगेटिव सब कुछ पढ़ने के लिए कठिन बना देता है।

— डैश-टॉम-बैंग

मैं जानता था कि एक देव जो चूतड़ मारता है, वह नहीं है; if (isNotConnected == true) ...

— yuck

Answer 15

आपको उसे बताना चाहिए कि वह गलत कर रहा है।

आईटी इस

अगर (सच == someBool) {

}

यदि वह कभी भूल जाता है = वह अपनी लेखन शैली में बड़ी परेशानी में है।

Answer 16

कैसा रहेगा

if (x == "true")

क्यों कि एक STRING है ?!

Comments

मैं कुछ विरासत php कोड पर सही काम कर रहा हूँ और कभी-कभी मुझे कुछ पसंद आता है if(preg_match('/title/', implode($_POST))){। PHP, पर्याप्त ने कहा, मुझे एक बेहतर नौकरी खोजने की आवश्यकता है।

— कीयो

हाँ, मैं यह भी देखता हूँ कि क्या है (x == "1"), लेकिन यह आमतौर पर खराब db डिज़ाइन के लिए होता है।

— atfergs

xउपयोगकर्ता इनपुट (कॉन्फ़िगरेशन फ़ाइल या वेब सेवा, उदाहरण के लिए) से आने पर मैंने इसी तरह के निर्माण का उपयोग किया है । हालाँकि, मैं आम तौर पर अन्य तुच्छ मूल्यों की अनुमति देता हूं, इसलिए यह अधिक समाप्त होता है जैसेif x.lower().strip() in ["true", "yes", "on", "1"]

— १

Answer 17

वास्तव में, यदि यह अशक्त है, तो x == सत्य के लिए परीक्षण आवश्यक होगा। :)

Answer 18

मैं जैसे कोड लिखता हूँ!

यहाँ क्यों है:

"if bla == true" एक वाक्य की तरह पढ़ता है, जहाँ "if bla" कई मामलों में नहीं होता है। यह सिर्फ गलत लगता है, जब वास्तविक कोड को बेचना।

इसके अलावा संकलक अगर ब्लॉक में असाइनमेंट के बारे में चेतावनी देता है, तो वास्तव में == का उपयोग करने में कोई खतरा नहीं है। (इसे लेकर भ्रमित होना =)

उन लोगों को भी करें जो "== सच" नहीं लिखते हैं, "== (" = "असत्य)" के लिए उपयोग करें? मुझे यह वास्तव में बदसूरत लगता है। और यदि आप "== असत्य" का उपयोग करते हैं, तो यह सत्य को सत्यापित करने के दो अलग-अलग तरीकों के बजाय "== सत्य" का उपयोग करने के लिए भी बहुत सुसंगत है।

Comments

आप कहते हैं कि "अगर bla" एक वाक्य की तरह नहीं पढ़ता है ... तो इसका मतलब है कि आपके वेरिएबल का नाम ठीक से नहीं है ... इसमें गलत क्या है: if (userHasRights) doSomething ()

— JoelFan

"कई मामलों में"। हाँ आप सही है। नाम बदलना भी ठीक है। "अगर (QWidget :: acceptDrops (= = true)" के साथ आपका नाम बदलने की संभावना नहीं है। शायद इसे नाम देना अच्छा होगा ।AcceptDrops () ... यह एक परेशानी का बहुत अधिक है (और किसी भी एपीआई में उस चूक-नियम का उपयोग करना लगातार असंभव है), इसलिए अन्य "== जो भी" के साथ संगत हो, मैं दृढ़ता से इसे छोड़ने का सुझाव नहीं देता हूं, इसलिए यह अलग नहीं दिखता है, इस प्रकार सुसंगत दिखता है।

— रॉनी ब्रेंडल

Answer 19

याद रखें कि आप एक टीम के हिस्से के रूप में काम कर रहे हैं, इसलिए आपको इन चीजों को एक साथ करने की आवश्यकता है। "दूसरों के साथ अच्छा खेलता है" प्राथमिक विद्यालय के बाद भी एक महत्वपूर्ण व्यक्तित्व विशेषता है :)

Answer 20

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

Comments

इसके अलावा, अगर यह टीम के कोडिंग मानकों में है, तो आपको वास्तव में इस तरह से सामान्य ज्ञान से छुटकारा पाने के लिए मानकों का पुनर्मूल्यांकन करना होगा।

— जॉनफैक्स

माना! बस के मामले में हालांकि ...

— FinnNk

Answer 21

हालांकि मैं मुख्य रूप से C # डेवलपर के रूप में सहमत हूं, मैं यह नहीं कह सकता कि यह हमेशा मामला है। उदाहरण के लिए, जावास्क्रिप्ट में, === टाइप कोलेसेंस करेगा। तो वर्जन x = 3 तब मान कर :

if(x) --> true

जबकि

if (x === true) --> false

मुझे लगता है कि जेएस में भी == से अलग है अगर मैं (x == सच) का उपयोग नहीं करेगा, लेकिन सिर्फ कुछ के बारे में सोचने के लिए।

इस तरह का एक और बिंदु पर स्पर्श होता है, जो मेरे कार्यालय में आया है:

bool b = false;

सी # में, बूल बी; पर्याप्त होगा और असत्य के लिए ख को अशुभ करेगा । हालांकि, उपरोक्त रेखा को लिखना अधिक स्पष्ट है और वैसे भी अनुकूलन के दौरान संकलक द्वारा बाहर निकाल दिया जाना चाहिए।

इसलिए मुझे लगता है कि मेरी बात यह हमेशा स्पष्ट नहीं है कि क्या अच्छा है और यह अच्छा अभ्यास नहीं है और इसका बहुत कुछ प्राथमिकता के साथ-साथ भाषा की विशेषताओं / quirks पर भी है।

Comments

bool b;केवल bएक क्षेत्र होने पर झूठे के लिए इनिशियलाइज़ करता है। आपको स्थानीय चर को स्पष्ट रूप से प्रारंभ करना होगा।

— मैथ्यू फ्लेशेन

+1 से सहमत हुए। अन्य (स्क्रिप्टिंग) भाषाओं के साथ भी यही मुद्दा है। यदि आप बूलियन trueया केवल "सच" के लिए परीक्षण करना चाहते हैं तो आपको स्पष्ट होना चाहिए । उदाहरण के लिए, किसी भी गैर-रिक्त स्ट्रिंग को माना जाता है, == trueलेकिन === trueकुछ भाषाओं में नहीं ।

— मार्टिन विकमैन

Answer 22

आह हाँ, लेकिन क्या होगा अगर चर अशक्त है? (Bool?)

कुछ भाषाओं (C #) के लिए 'सत्य' की आवश्यकता होगी और डाली या तुलना की जाएगी।

bool? isAccepted = true;

if((bool)isAccepted)
{...}

if(isAccepted == true)
{...}

Answer 23

युवा नियमों को जानते हैं, लेकिन पुराने अपवादों को जानते हैं;)

नवीनतम में C#, यदि आप एक के साथ काम कर रहे हैं null-able bool, तो आपको निम्न करना होगा:

bool? x = null;
bool? y = true;
bool? z = false;
if (x == true || y == true || z == true) {
    // That was the only way that is reasonably readable that I know of
    // to accomplish this expression.
}

यदि ट्रिस्टेट कोई समस्या नहीं है, तो आमतौर पर कुछ को true/ से तुलना करने का कारण नहीं होना चाहिए True। हालाँकि, Pythonऔर कई अन्य भाषाओं जैसे कि C/C++आप ifएक गैर-बूल अभिव्यक्ति पर प्रदर्शन कर सकते हैं । इन भाषाओं में पूर्णांकों, बिंदुओं, सूचियों आदि की व्याख्या के लिए अद्वितीय नियम हैं, या तो सही या गलत। शायद ही कभी आप ऐसा नहीं चाहते हैं। उदाहरण के लिए, इस पायथन स्निपेट में:

x = True
y = 'abcdef'
z1 = x and y
z2 = (x == True) and (y == True)

यहां zहोना चाहिए True, लेकिन z2होना चाहिए False। अब, एक Clojureभाषा इस तरीके से एक और तरीके से संपर्क करती है - वहाँ andफ़ंक्शन आवश्यक रूप से मूल्यांकन नहीं करता है bool, लेकिन ifइसे संभाल सकता है।

भाषा की परवाह किए बिना, किसी भी समय आप अपने आप को करने के लिए कुछ की तुलना पाते हैं Trueया False, यह शायद टिप्पणी के लायक है।

Comments

पहली समस्या एक गलत आधार IMO से भयानक चर नाम का उपयोग करके उपजी है। मान लीजिए एक्स, वाई, जेड के नाम थे notExceptButHasX, exceptNotButIsntY, doNotUnlessIsExceptZ? यह आपकी समस्या में पठनीयता के लिए कैसे करता है? एक्स, वाई, जेड "IsEnabled" जैसे कुछ नाम थे हैं, "isEffective", "hasProperty", तो अपने बयान हो जाता है isEnabled || isEffective || hasPropertyजो कहीं अधिक की तुलना से पठनीय trueया false।

— थॉमस

Answer 24

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

मुझे इस तरह की कोडिंग शैली के कारण पिछले साल बहुत ही सूक्ष्म बग का सामना करना पड़ा, जिसे पहचानना मुश्किल था क्योंकि किसी की नजर ऐसे निर्माणों पर पड़ती है। आप सोचेंगे, "यह गलत कैसे हो सकता है?" वही अच्छी तरह से समझे जाने वाले भावों के लिए "(var)" या "(! Var)" के रूप में सही है, जिसे आप उनके व्यवहार को सत्यापित किए बिना पढ़ते हैं या कोड करते हैं।

इसलिए मैंने कोडबेस में इस तरह के कीड़े के अस्तित्व को कम करने के लिए कोडिंग मानकों की एक जोड़ी पेश की है और संभावना है कि भविष्य में कुछ समय में ऐसे सूक्ष्म कीड़े गलती से रेंगेंगे।

1. सभी भावों को उनके इरादे के अनुसार छोटा किया जाना चाहिए।
2. सभी बूलियन परीक्षणों को "ऐसेबूल! = गलत" जैसे नकारात्मक रूप में व्यक्त किया जाना चाहिए।

नई शैली के अनुरूप कोड की सफाई करके, मैंने ऐसे सूक्ष्म कीड़े के कुछ और उदाहरणों की पहचान की है और उन्हें ठीक किया है।

Comments

TRUE / FALSE के अलावा कुछ और होने में सक्षम कुछ बूल कोडिंग प्रथा है।

— अटैकिंगहोबो

@AttackingHobo, यह एक भाषा में बूलियन प्रकार नहीं होने और / या सही व्यवहार प्रदान करने के लिए एक वर्ग का उपयोग नहीं करने के नुकसान में से एक है।

— Huperniketes

Answer 25

एक्शनस्क्रिप्ट 2 में हर समय इसका उपयोग करना था (क्योंकि अब एक मृत भाषा है), क्योंकि:

var something:Boolean = org.black.box.unknown.ThisMightNotExistYet();

// this is slightly ambiguous
if(something)
{
}

// because if you allow undefined you might actually mean
if(false != something)
{
}

// which can mean something different than
if(true == something)
{
}

// and comparing against what you actually MEAN is less script than
if(undefined != value && value)
{
}

इसलिए विशिष्ट होना लगभग हमेशा सबसे अच्छा था।

Answer 26

मैं सहमत हूँ। यह एक निरर्थक निर्माण है, विशेष रूप से मजबूत टाइपिंग भाषाओं में।

बूलियन्स का एक और दुरुपयोग जोड़ने के लिए, मैंने इस तरह के निर्माण को जावास्क्रिप्ट में कई बार पाया है, (विशेषकर कुछ स्पेगेटी जैसे राक्षस कार्यों में, 100+ लाइनों में):

//create the variable, not initializing it
var flag;
//...
//assing a value to the var, by the example 
flag=$("mycheckbox").selected;
//...

//and at the moment of use it:
if(flag!=true) {
   //code to execute when the checkbox is unchecked
}

ऐसा लगता है, इस भाषा में एक सख्त प्रकार की परिभाषा की कमी के कारण, कुछ प्रोग्रामर पसंद करते हैं कि वे false|undefinedमूल्यों के साथ खिलवाड़ न करें ।

Answer 27

मेरा एक सहयोगी है जिसके पास कुछ कोड होंगे:

if(something == true)

और फिर, किसी प्रकार के परीक्षण / डिबगिंग के लिए, वह इस ब्लॉक को नहीं बुलाना चाहेगा, इसलिए वह इसे बदल देगा:

if(something == true && false)

और फिर कभी-कभी वह इसे बदल देगा:

if(false)

सबसे बुरी बात यह है कि इस प्रकार की डिबगिंग ने मुझे इस अवसर पर उकसाया है और अन्य डेवलपर्स के लिए पढ़ना बहुत बुरा है!

Answer 28

मैं कहूंगा कि एक कोडबेस में स्थिरता राजा है। तो आपको शैली का उपयोग करना चाहिए, जो कि ज्यादातर आपके संगठन में उपयोग किया जाता है। अपनी पसंदीदा शैली को आधिकारिक कंपनी कोडिंग दिशानिर्देशों का हिस्सा बनाने का प्रयास करें। यदि यह पहले से ही दिशानिर्देशों में है, तो इसका पालन करें।

(यह कहा जा रहा है, यह वास्तव में मुझे भी परेशान करेगा - लेकिन शायद इससे बाहर एक बड़ा सौदा करने के लिए पर्याप्त नहीं है)।

Answer 29

मैं अतिरिक्त == सही नहीं रखना पसंद करता हूं, लेकिन कभी-कभी मैं गलती से इसे शामिल करता हूं और इसे नोटिस नहीं करता। हो सकता है कि व्यक्ति ने गौर न किया हो और गलती से उन्हें रख दिया हो। मैं अपने कोड को पुनः लिखता हूं और कभी-कभी ध्यान देता हूं कि मैंने अतिरिक्त == सत्य रखा है इसलिए मैं उस == सत्य को हटा देता हूं। मैं कभी-कभी इसे नोटिस नहीं करता और खुशी से किसी का स्वागत करते हुए कहता कि मैंने इसे बेमानी तरीके से रखा है।

Answer 30

कैसा रहेगा:

int j = 1;
for (int i=1; i>=j; i++) ...

हां, मैंने इसे देखा है।