क्यों का प्रयोग करें?

59

इस सवाल पर एक टिप्पणी: यह जाँचना कि क्या कोई विधि गलत है: परिणाम को अस्थायी चर पर नियत करें, या सशर्त में सीधे विधि मंगलाचरण डालें? कहता है कि आप का उपयोग करना चाहिए !booleanके बजाय boolean == falseजब स्थिति का परीक्षण। क्यों? मेरे boolean == falseलिए अंग्रेजी में बहुत अधिक प्राकृतिक है और अधिक स्पष्ट है। मैं माफी मांगता हूं कि क्या यह सिर्फ शैली का मामला है, लेकिन मैं सोच रहा था कि क्या इस प्राथमिकता का कोई और कारण था !boolean?

language-agnostic coding-style boolean

— ईएलएस
स्रोत

28

यह लिखना कम है।

— ज़ेनॉन

39

यह करने जैसा है boolean == true: इसका कोई मतलब नहीं है। ifबयानों के अंदर अभिव्यक्तियाँ बस यही हैं: भाव। अगर कुछ पहले से ही एक बूलियन अभिव्यक्ति का मूल्यांकन करता है, तो आप उस पर मूल्यांकन करने के लिए उसे मजबूर करने के लिए एक जांच क्यों जोड़ेंगे?

— मैक्सएम

10

@zzzzBov: उम, नहीं। यही नहीं अधिकांश (सी-शैली) प्रोग्रामर इसे करते हैं।

— अमारा

9

@zzzzBov: आपकी टिप्पणी अस्पष्ट है। यदि आपका मतलब है कि !boolean_variableजिस तरह से अधिकांश सी प्रोग्रामर इसे करते हैं, मैं सहमत हूं।

— कीथ थॉम्पसन

29

और इससे भी महत्वपूर्ण बात यह है कि कोई कैसे लिखना चाहता है boolean != true?

153

जब मुझे एक पंक्ति दिखाई देती है if (!lateForMeeting()), तो मैं पढ़ता हूं कि "अगर बैठक के लिए देर नहीं हुई" , जो समझने में काफी सीधा-सीधा है, जिसके विरोध के रूप में if (lateForMeeting() == false)मैं पढ़ूंगा "यदि तथ्य यह है कि मुझे बैठक के लिए देर हो रही है तो गलत है ” ।

वे अर्थ में समान हैं, लेकिन पूर्व के करीब है कि कैसे समान अंग्रेजी वाक्य का निर्माण किया जाएगा।

— रेव्ह काबा
स्रोत

27

+1 पायथन में आप वास्तव में लिखते हैं if not late_for_meeting:)

— phunehehe

42

मैं तर्क देता हूं कि यदि "यदि ___ गलत है" तो "नहीं ___" से अधिक स्वाभाविक लगता है, तो ___ के नाम में सुधार की आवश्यकता है।

— माइक डेसिओन

12

पर्ल में आप लिख सकते हैंunless late_for_meeting

— हेनरिक रिपा

4

@ हेनरिक रिपा: ऐसा लगता है कि आप जो कुछ भी टाइप कर सकते हैं, वह पर्ल में कानूनी कोड है। आप जो चाहते हैं, वह एक और सवाल है या नहीं;)

— एडम रॉबिन्सन

4

@ ए-क्यूब मेरे पास शुरू करने के लिए ऐसा तरीका नहीं होगा। इसके बजाय, मेरे पास एक विधि होगी done()। डबल नेगेटिव खराब हैं।

— kba

97

लिखना == falseऔर == trueबेमानी है। इसे मनमाना चरम सीमा तक भी ले जाया जा सकता है। अगर आप लिखना शुरू करते हैं

if (condition == false) { ... }

फिर क्यों नहीं

if ((condition == false) == true) { ... }

या क्यों नहीं

if ((someExp == anotherExp) == true) { ... }

इस कहानी का नैतिक यह है कि अगर conditionएक बूलियन अभिव्यक्ति है, तो आपको जोड़ने की आवश्यकता नहीं है == false; ऑपरेटर किसके !लिए है;)

— एंड्रेस एफ।
स्रोत

यह नहीं सोचा था!

— ell

51

== falseबेमानी नहीं है, बस से अधिक क्रिया है !। OTOH, == trueबेमानी है।

— dan04

4

@ dan04 तुम सही हो। हालाँकि, इस अर्थ में, मेरा मतलब था, यह एक बुरा विचार है। (exp1 != exp2)बनाम पर विचार करें ((exp1 == exp2) == false)। निस्संदेह, ये आकस्मिक परिदृश्य हैं, लेकिन फिर भी आपको लगभग कभी भी सही या गलत की तुलना नहीं लिखनी चाहिए। जैसे आपको ऑपरेटर का उपयोग करना चाहिए !=, वैसे ही आपको भी उपयोग करना चाहिए !।

— एंड्रेस एफ।

26

@ dan04: यह बेमानी है जब भाषा पहले से ही प्रदान करती है !।

— डेडएमजी

5

@ dan04: किसी भी समय आप लिखते हैं bool_expression == bool_literal, == ...बेमानी है। चाहे आप सही या गलत के लिए परीक्षण कर रहे हों, अप्रासंगिक है। यह परिणामी / वैकल्पिक ब्लॉकों के क्रम में सिर्फ एक बदलाव है। एंड्रेस के उदाहरण इस बिंदु को पूरी तरह से चित्रित करते हैं। अधिकांश आधुनिक कंपाइलर्स अतिरेक को दूर कर देंगे, लेकिन यह अभी भी बेमानी है।

— लेस मेजेस्टे

70

सी और कुछ समान भाषाओं में, समानता के लिए बूलियन अभिव्यक्तियों की तुलना करना falseया trueएक खतरनाक आदत है।

सी में किसी भी स्केलर एक्सप्रेशन (न्यूमेरिक या पॉइंटर) का उपयोग बूलियन संदर्भ में किया जा सकता है, उदाहरण के लिए ifस्टेटमेंट की स्थिति के रूप में । सी नियम यह है कि if (cond)बराबर है if (cond != 0)- अर्थात, शून्य गलत है, और कोई भी गैर-शून्य मान सत्य है। यदि condपॉइंटर प्रकार का है, 0एक अशक्त पॉइंटर स्थिरांक के रूप में माना जाता है; if (ptr)का मतलब है if (ptr != NULL)।

इस का मतलब है कि

if (cond)

तथा

if (cond == true)

एक ही बात का मतलब नहीं है । condगैर-शून्य होने पर पहला सच है; दूसरा तभी सही है जब वह बराबर हो true, जो C में (यदि आपके पास है #include <stdbool.h>) बस है 1।

उदाहरण के लिए, isdigit()फ़ंक्शन <ctype.h>रिटर्न में एक intमूल्य घोषित करता है , 0यदि तर्क एक अंक है, तो गैर-शून्य यदि यह नहीं है। यह 42इंगित करने के लिए वापस आ सकता है कि स्थिति सच है। तुलना 42 == trueकरना विफल हो जाएगा।

ऐसा होता है कि 0एक ही मूल्य को गलत माना जाता है, इसलिए समानता के लिए तुलना falseकरना काम करेगा; if (!cond)और if (cond == false)वही काम करो। लेकिन अगर आप इसका फायदा उठाने जा रहे हैं, तो आपको याद रखना होगा कि तुलना करना falseठीक है, और तुलना करना ठीक trueनहीं है। अभी तक की तुलना में, सबसे अधिक समयtrue काम करेगा (उदाहरण के लिए, समानता और संबंधपरक ऑपरेटर हमेशा या तो उपज देते हैं )। इसका मतलब यह है कि आपके द्वारा उपयोग किए जाने वाले किसी भी कीड़े को अभी भी नीचे ट्रैक करना मुश्किल हो सकता है। (चिंता न करें, जैसे ही आप किसी महत्वपूर्ण ग्राहक को कोड प्रदर्शित करेंगे, वे दिखाई देंगे।)01

सी ++ में थोड़ा अलग नियम हैं; उदाहरण के लिए, इसका boolप्रकार भाषा में थोड़ा अधिक कसकर एकीकृत है, और टाइप करने के लिए if (cond)कनवर्ट करता condहै bool। लेकिन प्रभाव (ज्यादातर) एक ही है।

कुछ अन्य भाषाओं एक क्या बेहतर व्यवहार किया बूलियन्स, ऐसी है कि कॉल कर सकते है cond == trueऔर cond == false(या जो भी वाक्य रचना होने के लिए होता है) सुरक्षित है। फिर भी, मैंने जो भी भाषा देखी है उसमें एक notया एक !ऑपरेटर है; यह वहां है, इसलिए आप इसका उपयोग कर सकते हैं। का उपयोग cond == falseकरने के बजाय !condया not condनहीं, मेरी राय में, पठनीयता में सुधार करता है। (यह सच है कि !चरित्र को एक नज़र में देखना मुश्किल हो सकता है; मैं इससे !बचने के लिए कभी-कभी एक स्थान जोड़ देता हूं ।)

और अक्सर आप इस मुद्दे से बच सकते हैं और कोड को फिर से व्यवस्थित करके स्पष्टता में सुधार कर सकते हैं। उदाहरण के लिए, इसके बजाय:

if (!cond) {
    do_this();
}
else {
    do_that();
}

आप लिख सकते हैं:

if (cond) {
     do_that();
}
else {
    do_this();
}

यह हमेशा बेहतर नहीं होता है, लेकिन यह उन अवसरों की तलाश में चोट नहीं करता है जहां यह है।

सारांश: सी और सी ++ में, समानता की तुलना trueऔर falseखतरनाक, अत्यधिक क्रिया और खराब शैली से की जाती है। कई अन्य भाषाओं में, इस तरह की तुलना खतरनाक नहीं हो सकती है, लेकिन वे अभी भी बहुत खराब और खराब शैली के हैं।

— कीथ थॉम्पसन
स्रोत

इसके लिए +1 वास्तविक उपयोगी तकनीकी स्पष्टीकरण के साथ एक उत्तर है।

— माइक नाकिस

मैं अब भी इस तरह से सोचता हूं, प्रोग्रामिंग भाषा की परवाह किए बिना मैं हमेशा मानता हूं कि == trueअसुरक्षित है। इस तरह से बेहतर महसूस होता है।

— Dervall

1

@ डर्वॉल: ऐसा कुछ मान लेना, बस ऐसा नहीं है, यह भी अच्छा नहीं है। कुछ भाषाओं में कुछ कोने के मामले हैं जहां बूलियंस की समानता की तुलना न केवल सुरक्षित है, बल्कि वास्तव में उपयुक्त है, उदाहरण के लिए हास्केल में, जिसमें द्विदिश प्रकार के इंजेक्शन के साथ एक मजबूत अंतर्निहित-कास्ट-फ्री प्रकार प्रणाली है, (==True) . fजिसे स्पष्ट करने के लिए कोई लिख सकता है हम -> Boolरिटर्न-पॉलीमॉर्फिक फ़ंक्शन का इंस्टेंटेशन चाहते हैं f। की तुलना में not . not . fकम स्पष्ट और अजीब है (f :: a -> Bool)।

— लेफ्टनैबाउट

इसके अलावा, यह निश्चित रूप से pred(x)==pred(y)एक बूल-रिटर्न फ़ंक्शन के लिए सामान करने के लिए उपयुक्त है pred। विकल्प यह होगा pred(x)? pred(y) : !pred(y)कि आप सहमत होंगे कि शायद ही स्वीकार्य हो।

— लेफ्टरनैबाउट

1

@leftaroundabout: यदि आप जानते हैं कि यह ठीक है pred(x)और pred(y)सत्य को निरूपित करने के लिए उसी मूल्य का उपयोग करते हैं, जो कुछ भाषाओं में एक सुरक्षित धारणा है, लेकिन दूसरों में नहीं। सी में, उदाहरण के लिए, आप लिख सकते हैं !!pred(x) == !!pred(y)।

— कीथ थॉम्पसन

13

यदि आपके condition == falseलिए वास्तव में "अंग्रेजी में बहुत अधिक प्राकृतिक" है तो मुझे यह मानना होगा कि आप मूल वक्ता नहीं हैं। अन्यथा मैं यह नहीं समझा सकता, क्योंकि कोई भी इस तरह से नहीं बोलता:

अगर सूरज चमक रहा है तो मैं घर पर ही रहूंगा।

की तुलना करें

अगर सूरज नहीं चमक रहा है तो मैं घर पर ही रहूंगा।

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

जिन भाषाओं की आवश्यकता होती है !, उनके लिए मैं ऑपरेटर और ऑपरेटर के बीच एक स्थान रखता हूं। यह अनदेखी को और अधिक कठिन बना देता है:

if (! condition) { … }

ध्यान दें कि प्रत्येक प्रोग्रामर को अपने आप यह अनुवाद करना चाहिए , बिना दूसरे विचार के, उनके सिर में "शर्त नहीं"। कोड मुहावरों को पढ़ने में इस तरह के प्रवाह को प्राप्त करना एक अच्छा प्रोग्रामर बनने के पहले चरणों में से एक है।

— कोनराड रूडोल्फ को दर्शाता है
स्रोत

13

दो कार्यात्मक रूप से समान हैं, इसलिए जिसका उपयोग करना स्वाद का मामला है।

मेरे द्वारा उपयोग किए जाने == falseका प्रमुख कारण यह है कि मैंने पाया है कि !कोड को देखते समय, अनदेखी करना बहुत आसान है।

इसके द्वारा गंभीर रूप से काटे जाने के बाद, मैंने झूठ के लिए परीक्षण करते समय इसे बहुत स्पष्ट करने की आदत बना ली है।

अगर ऑपरेटर का नाम notपास्कल होता, तो मुझे नहीं लगता कि यह एक मुद्दा बन जाता।

— उपयोगकर्ता 1212 को रिवाइज करता है
स्रोत

5

इस कारण से, कुछ मेडिकल डिवाइस सॉफ़्टवेयर के लिए मैंने जिस C ++ प्रोजेक्ट पर काम किया था, उसमें एक कोडिंग मानक था, जो इसी कारण == falseके !लिए अनिवार्य था (इसे बाहर खड़ा करने के लिए)। हालांकि == true, उपयोग करने की कोई आवश्यकता नहीं थी , इसलिए किसी भी गैर-शून्य मूल्य ने अभी भी वैसा ही काम किया जैसा कि करना चाहिए।

— tcrosley

12

मैंने हमेशा इस तर्क को असंबद्ध पाया है - C / C ++ / C # / Java / etc में अन्य स्थान हैं जहाँ किसी एक वर्ण को देखने में असफल रहने से कोड की व्याख्या पर समान रूप से महत्वपूर्ण प्रभाव पड़ता है; अलग करना "!" एकमात्र बुरा के रूप में मेरे लिए कोई मतलब नहीं है।

— बेवन

5

@bevan जाहिर है आपको अभी तक नहीं काटा गया है।

1

जबकि मैं मानता हूं कि !इस तरह की सबसे अधिक परेशानी वाली गलती है, यह IMO को लिखने की आदत बनाने के लिए नहीं ==falseबल्कि बेहतर इकाई परीक्षण लिखने के लिए देना चाहिए ।

— 13

8

@ ThorbjørnRavnAndersen काफी उल्टा - मुझे वर्षों से अक्सर काट लिया जाता है जो मैंने खुद को हर चरित्र को पढ़ने के लिए सिखाया है । मैं उस कोड के सभी (या यहां तक कि सबसे) का लेखक नहीं हूं, मुझे दिन-प्रतिदिन पढ़ना पड़ता है, इसलिए किसी भी व्यक्तिगत सम्मेलन के बारे में, जिसकी हम यहां चर्चा कर रहे हैं, इसका न्यूनतम मूल्य है: मुझे अपने द्वारा पढ़े गए सभी कोड को सही ढंग से समझने की आवश्यकता है , नहीं अभी जो सामान मैंने लिखा है।

— बेवन

7

जब मैं देख रहा हूँ var == falseमैं हमेशा आश्चर्य है कि क्या varबूलियन या दो से अधिक मूल्यों के साथ एक तर्क प्रकार का है (के साथ, उदाहरण के लिए, एक के लिए maybeऔर एक undefinedके साथ-साथ trueऔर false, या की तरह कुछ आईईईई 1164 नौ मूल्यों )।

— एपीग्रामग्राम
स्रोत

8

तीसरा मान आमतौर पर "फ़ाइल नहीं मिली" है। thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx

— Groky

6

क्योंकि कभी-कभी आप boolean = false(स्पष्ट त्रुटियों के साथ) लिख सकते हैं और false == booleanयह स्वाभाविक नहीं लगता (चाहे वह कितना भी अच्छा अभ्यास क्यों न हो)

— शाफ़्ट सनकी
स्रोत

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

— ड्रिप चैपिन

यदि आप एक स्थैतिक विश्लेषण उपकरण का उपयोग करते हैं, तो यह आपको सौ गुना अधिक सिर-दर्द से बचाएगा, और आप प्रकृति hFile==INVALID_HANDLE_VALUE लेखन को पुनर्स्थापित करने में सक्षम हैं ।

— गक्क्निबग

4

if (!boolean_variable)में अनुवाद करता है if the condition is not true।

if (boolean == false)में अनुवाद करता है if the condition not false is true। क्योंकि जो उलटा तर्क है, उसे समझना कठिन है।

— BЈовић को दर्शाता है
स्रोत

3

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

— रॉबिंस

1

@ S.Robins मुझे बूलियन वैरिएबल के लिए बूलियन का बेवकूफ नाम मिलता है। उदाहरण के लिए कुछ isVisibleबेहतर उदाहरण होगा। तब if (!isVisible)मतलब होगा अगर दिखाई नहीं दे रहा है - जो कि तब समझने में सरल है if (isVisible==false), जो कि एक उलटा तर्क है। उम्मीद है कि अब यह स्पष्ट हो जाएगा। या, क्या मैंने आपकी टिप्पणी को गलत समझा?

— B

2

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

यह कहा जा रहा है, मेरा मानना है कि नए संकलक इस के साथ दूर करते हैं, इसलिए यह या तो साथ जाने के लिए ठीक होना चाहिए।

— lcllam
स्रोत

मशीन कोड बनाना कंपाइलर का काम है, न कि उच्च-स्तरीय भाषा प्रोग्रामर का ...

— एक CVn

ऐतिहासिक कारणों के लिए, यह बहुत अच्छी तरह से एक कारण हो सकता है कि एक विधि दूसरे पर पसंद की जाती है।

— पैरोल

1

काम पर मैं अक्सर बूलियन्स के साथ काम कर रहा हूं जो कि अशक्त हो सकता है इसलिए मैं अक्सर इस मामले को कोड करूंगा

if (value != null && value == true){
    //do something
}

क्योंकि मुझे व्यक्तिगत रूप से लगता है कि समरूपता को पढ़ना आसान हो जाता है। खासकर अगर वहाँ अन्य बूलियन के रूप में अच्छी तरह से परीक्षण किया जा रहा है।

मैं वास्तव में एक तरह से या दूसरे की परवाह नहीं करता।

— WuHoUnited
स्रोत

4

अगर value == trueफिर भी यह जाँचने का कोई कारण नहीं है कि यह अशक्त नहीं है। यदि value == nullयह पहली बार में बयान को ट्रिगर नहीं करना चाहिए, तो if (value)पर्याप्त होना चाहिए।

— zzzzBov

1

बूलियन ऑब्जेक्ट हैं (जावा में) और इसलिए अशक्त हो सकता है इसलिए केवल if (value)एक अपवाद को फेंकता है। मैं इसकी सराहना करता हूँ अगर जो लोग नीचा दिखाते हैं वे एक कारण देते हैं।

— वूहोइनटेड

3

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

— ऑबर्जिन

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

2

@UHoUnited, भले ही मूल्य शून्य था, value == trueपर्याप्त होगा।

— zzzzBov

1

जब आप वास्तविक स्थिति का परीक्षण कर रहे होते हैं, तो यह सिर्फ करने के लिए समझ में आता है if (condition), खासकर जब आप नामकरण बूलियन चर के कन्वेंशन को 'इज़' से शुरू करते हैं: if (isOpen)पूरी तरह से स्पष्ट है और इसका उपयोग != falseकरना बेमानी होगा।

C / C ++ / Java / etc के लिए। प्रोग्रामर, 'का अर्थ है!' ऑपरेटर को पूरी तरह से आत्मसात किया जाता है, इस बिंदु पर कि जब हम देखते हैं तो हमारे मन में स्वचालित रूप से 'नहीं' है। तो मेरे लिए if (!isOpen)उतना ही स्पष्ट if (_NOT_ isOpen)है। लेकिन आप पर्याप्त परिचित नहीं हैं, C / C ++ में आप एक मैक्रो बना सकते हैं #define _NOT_ !। लेकिन मेरा विश्वास करो, कुछ वर्षों के बाद यह पूरी तरह से अनावश्यक है।

इसके अलावा, बूलियन मूल्यों को शाब्दिक रूप से तुलना किए बिना परीक्षण करना हमेशा बेहतर होता है। उदाहरण के लिए, यह परीक्षण करना खतरनाक है if (x == true)क्योंकि एक बूलियन मान को सत्य माना जाता है यदि यह शून्य नहीं है, और शाब्दिक सत्य का केवल एक विशिष्ट मूल्य है, इसलिए x 'सत्य' (यानी नॉनजेरो) हो सकता है और अभी भी तुलनात्मक मूल्यांकन गलत है (क्योंकि यह 2 शामिल हैं और शाब्दिक सच है, कहते हैं, 1.) बेशक जो झूठ के साथ एक तुलना पर लागू नहीं होता है, लेकिन अगर आप इसका उपयोग सच के लिए परीक्षण करते समय नहीं करते हैं, तो झूठे के लिए परीक्षण करते समय इसका उपयोग क्यों करें?

— फैबियो सेकोनेलो को दर्शाता है
स्रोत

यह आवश्यक नहीं है कि आप जिस C ++ मैक्रो को C ++ के रूप में प्रस्तावित करते हैं उसे पहले से ही 'न' समझ लें। संबंधित: stackoverflow.com/questions/2393673/c-and-or-not-xor-keywords

— frozenkoi

यह सच है, लेकिन यह केवल C ++ 0X मानक के लिए एक कीवर्ड है। इससे पहले, यह सिर्फ एक और मैक्रो था।

— Fabio Ceconello

0

आकर महत्त्व रखता है ;)

मिश्रित अभिव्यक्तियों में इसे पढ़ना आसान है:

boolean1 = false
boolean2 = true

p ! boolean1 and ! boolean2
p boolean1 == false and boolean2 == false

और माणिक के लिए विशिष्ट जहां यह एक बड़ा अंतर है:

boolean = nil
p ! boolean         #-> true
p boolean == false  #-> false

शून्य झूठ नहीं है, लेकिन यह भी सच नहीं है।

— नूट
स्रोत

0

मेरे अनुभव और मेरे उद्धरण से जो आपने लिंक किया है, उसके जवाबों के आधार पर।

कुछ लोग अगर (शर्त) का उपयोग करना पसंद करते हैं, तो इस कारण से कि यह लिखना कम है। और मेरे लिए यह वास्तव में समझ में आता है, उदाहरण के लिए (isValidated ()) मैंने इसे नहीं पढ़ा है। लेकिन मेरे लिए यह सब व्यक्तिगत प्राथमिकताओं पर आधारित है, और यह तार्किक संरचना की तार्किक संरचना पर निर्भर करता है () विधि, अगर यह या तो सही है या गलत है

— KyelJmD
स्रोत

0

यदि आपने अपने चर को ठीक से नाम दिया है, तो !booleanअधिक स्वाभाविक है। यह not booleanकिसी को भी जो प्रोग्रामर के मानसिक रूप से कोड को पढ़ने के लिए पर्याप्त है के रूप में पढ़ता है ।

— ऑर्बिट में लाइटनेस दौड़
स्रोत

0

कुछ लोगों के लिए, जितनी जल्दी एक अर्थ बेहतर व्यक्त किया जाता है।

उन लोगों के लिए जो "अगर! ..." की तुलना तेजी से करते हैं "अगर ..." तो पूरी स्थिति के माध्यम से पढ़ने के लिए (जो वास्तव में बहुत लंबा हो सकता है, जैसे (यह थिंग = थिंग या कुछ = दूसरी बात) या ( thinga = thingb और thinga = thingd), आदि) अंत में बस == गलत खोजने के लिए।

होने! (मैं वास्तव में पसंद नहीं जब भाषा यह अनुमति देता है) ठीक सामने सामने अंग्रेजी में इस स्थिति के लिए 'नहीं' जल्दी ही मिल जाता है।

यह समस्या untilउन भाषाओं का उपयोग करने के लिए भी विचार करती है जो इसका समर्थन करती हैं, जैसे कि बात पूरी होने तक 'सामान्य सामान' करना। जैसा कि अन्य कहते हैं, प्राकृतिक भाषा अभिव्यक्ति लक्ष्य है। मुझे ऊपर "सूर्य चमक रहा है" उदाहरण पसंद है।

— जून्की
स्रोत

0

एक और कारण यह है कि यदि आप एक कोडबेस में काम कर रहे हैं, जो कई भाषाओं का उपयोग करता है, अगर ऐसा करने के लिए एक मुहावरेदार तरीका है जो सभी भाषाओं में सुरक्षित है, तो यह हर जगह इस तरह से करना बहुत अच्छा विचार है ताकि आप एक अच्छी आदत बना सकें और यात्रा करने की संभावना कम होती है।

मैं कहीं भी नहीं सोच सकता कि if (!variable)(या if not variableआपकी भाषा के आधार पर समतुल्य ) सुरक्षित नहीं है, जबकि उदाहरण के if self.is_ready() == False: ...लिए अजगर में सुरक्षित नहीं है यदि self.is_ready()रिटर्न None, अभी या भविष्य में, जो करने के लिए यह पूरी तरह से उचित बात होगी संकेत मिलता है कि यह तब से तैयार नहीं था जब तक कि यह Noneगलत है False।

— daphtdazz
स्रोत