object == null या null == ऑब्जेक्ट?

Question

मैंने किसी से सुना है जो चेक null == objectसे बेहतर हैobject == null

जैसे:

void m1(Object obj ) {
   if(null == obj)  // Is this better than object == null ? Why ?
       return ;
   // Else blah blah
}

क्या कोई कारण है या यह एक और मिथक है? सहायता के लिए धन्यवाद।

Comments

२ this१५६१ और १ ९ ५36३६ का डुप्लीकेट (सिवाय इसके कि यह 'जावा में' कहता है)

— गिषु

Java C #

— Jijoy

अगर वहाँ था एक महत्वपूर्ण प्रदर्शन लाभ है, तो यकीन है कि के लिए संकलक अनुकूलित हैं ...

— एंड्रियास Dolk

के लिए nullसंदर्भ, कार्रवाई के डिफ़ॉल्ट पाठ्यक्रम एक एनपीई फेंकने के लिए होना चाहिए। कुछ अच्छे पुस्तकालयों (जैसे कि JDK7 Java लाइब्रेरी) में एक विधि कुछ इस तरह है public static <T> T notNull(T obj) { if (obj == null) { throw new NullPointerException(); } else { return obj; } }। वहाँ भी @NonNull(या @Nonnull?) है, लेकिन "मिट" जाता है।

— टॉम हॉकिन -

null == objectएक योडा स्थिति के रूप में जाना जाता है ।

— सिरो सेंटिल्ली 郝海东 冠状 i i 法轮功 '

Answer 1

यह शायद सी से सीखी गई आदत है, इस प्रकार के टायपो से बचने के लिए (एकल के =बजाय सिंगल ==):

if (object = null) {

==जावा में वास्तव में बायीं ओर स्थिरांक रखने का सम्मेलन जावा में वास्तव में उपयोगी नहीं है क्योंकि जावा को मूल्य के ifमूल्यांकन में अभिव्यक्ति की आवश्यकता होती है boolean, इसलिए जब तक कि निरंतर एक नहीं है boolean, तब तक आपको संकलन त्रुटि मिल जाएगी। तर्क। (और अगर यह एक बूलियन है, तो आपको ==वैसे भी उपयोग नहीं करना चाहिए ...)

Comments

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

— रेडाई

एक विशिष्ट कोने के मामले को छोड़कर। stackoverflow.com/questions/2369226/null-check-in-java/…

— चंद्र सेकर

@ एक बूलियन के लिए, आप उपयोग x.booleanValue()या कर सकते हैं !x.booleanValue()। x == trueया x == falseएक स्थिति अभिव्यक्ति में एक खराब गंध है, IMHO।

— लॉरेंस गोंसाल्वेस

वह यहां अशक्त के लिए जाँच कर रहा है। और ऐसे मामले हैं जहां उसे वास्तव में अशक्त के लिए एक बूलियन की जांच करनी है क्योंकि अशक्त न तो सच है और न ही झूठ है।

— चंद्रा सेकर

null == objectकेवल यह सुनिश्चित करने के लिए उपयोग करने की आदत डालना कि हम किसी टाइपो के साथ गलती से ऑब्जेक्ट को अधिलेखित नहीं करते हैं, एक usecase बिल्कुल नहीं होना चाहिए। जिसका अर्थ है कि, हम खुद को प्रशिक्षित कर रहे हैं कि अब मैं पहले "अशक्त" का उपयोग करता हूं, ठीक है, भले ही मैं कोई गलती करूं। इसका मतलब यह नहीं है कि कोड उम्मीद के मुताबिक काम करता है। यहां तक कि अगर null = objectके स्थान पर दिया जाता है null == object, इस कार्यक्रम काम करने के लिए जा नहीं है के रूप में उम्मीद! फिर इस सम्मेलन का अनुसरण करने का कोई मतलब नहीं है!

— वनाग्सेस

Answer 2

जैसा कि दूसरों ने कहा है, यह टाइपो से बचने के लिए सी से सीखी गई एक आदत है - हालांकि सी में भी मैं चेतावनी देने के लिए उच्च पर्याप्त चेतावनी स्तरों पर सभ्य संकलक की उम्मीद करूंगा। जैसा कि चंद्रू कहते हैं, जावा में शून्य के खिलाफ इस तरह से तुलना करना केवल समस्याओं का कारण होगा जब आप प्रकार के चर का उपयोग कर रहे थे Boolean(जो आप नमूना कोड में नहीं हैं)। मैं कहूंगा कि यह एक बहुत ही दुर्लभ स्थिति है, और ऐसा नहीं है जिसके लिए यह आपके द्वारा हर जगह कोड लिखने के तरीके को बदलने के लायक है। (मैं इस मामले में भी ऑपरेंड को उलटने की जहमत नहीं उठाऊंगा; अगर मैं उन्हें उलटने पर विचार करने के लिए स्पष्ट रूप से पर्याप्त सोच रहा हूं, तो मुझे यकीन है कि मैं बराबर संकेत गिन सकता हूं।)

जो उल्लेख नहीं किया गया है वह यह है कि बहुत से लोग (निश्चित रूप से शामिल हैं) if (variable == constant)फॉर्म को अधिक पठनीय पाते हैं - यह अपने आप को व्यक्त करने का अधिक स्वाभाविक तरीका है। यह एक कारण है कि सी से एक कन्वेंशन को नेत्रहीन रूप से कॉपी न करें। आपको हमेशा अभ्यास करना चाहिए (जैसा कि आप यहां कर रहे हैं :) यह मानने से पहले कि एक वातावरण में क्या उपयोगी हो सकता है दूसरे में उपयोगी है।

Comments

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

— एड्रियन एम

Answer 3

यह जावा (1.5+) में बहुत अधिक मूल्य का नहीं है, सिवाय इसके जब ऑब्जेक्ट का प्रकार हो Boolean। किस मामले में, यह अभी भी काम कर सकता है।

if (object = null)जावा 1.5+ में संकलन विफलता का कारण नहीं होगा, यदि ऑब्जेक्ट है, Booleanलेकिन NullPointerExceptionरनटाइम पर फेंक देगा ।

Comments

आप शायद मतलब यह संकलन विफलता का कारण होगा :)

— vava

नहीं यह ऑब्जेक्ट बूलियन होने पर संकलन त्रुटि का कारण नहीं होगा।

— चंद्रा सेकर

क्या यह बूलियन के अलावा हर वस्तु प्रकार के लिए समान नहीं है?

— Ciro Santilli 郝海东 冠状 iro i 法轮功 '

गैर-बूलियन प्रकारों के लिए, कोड संकलित नहीं करेगा क्योंकि अभिव्यक्ति का प्रकार "ऑब्जेक्ट = नल" बूलियन नहीं होगा। ऑटो-बॉक्सिंग के कारण, यह बूलियन के लिए संकलन करेगा।

— चंद्रा सेकर

लेकिन बूलियन के लिए यह व्यवहार क्यों? कोई औचित्य?

— रोहित बंगा

Answer 4

जावा में कोई अच्छा कारण नहीं है।

अन्य जवाबों के एक जोड़े ने दावा किया है कि यह इसलिए है क्योंकि आप गलती से इसे समानता के बजाय असाइनमेंट बना सकते हैं। लेकिन जावा में, यदि आपके पास एक बूलियन है, तो यह है:

if (o = null)

संकलन नहीं करेंगे।

केवल एक बार जावा में यह बात हो सकती है यदि चर बूलियन है:

int m1(boolean x)
{
    if (x = true)  // oops, assignment instead of equality

Comments

लेकिन आप कभी भी == trueया समान रूप से क्यों लिखेंगे == true == true।

— टॉम हॉल्टिन -

लिखने का एक अच्छा कारण नहीं है == true। लेकिन मैंने अपने करियर में इतना बुरा कोड देखा है कि मैं अब यह नहीं पूछता कि कोई क्यों कुछ लिखेगा और सिर्फ यह स्वीकार करेगा कि कुछ लोगों ने अनावश्यक / संदिग्ध कोड लिखा है।

— आर सैमुअल क्लैत्को

वास्तव में, वहाँ बहुत सारे खराब कोड हैं, फिर भी, जब x == trueबुरा माना जाता है क्योंकि यह गलती से लिखा जा सकता है x = true, तो इसे true == xबदले में बहुत समझदारी नहीं होगी x।

— होल्गर

Answer 5

यह भी निकटता से संबंधित है:

if ("foo".equals(bar)) {

यदि आप एनपीई से निपटना नहीं चाहते हैं तो सुविधाजनक है:

if (bar!=null && bar.equals("foo")) {

Comments

सुविधाजनक हो सकता है, लेकिन खतरनाक हो सकता है नीला-walrus.com/2010/11/…

— ओलिवर वाटकिंस

@ ओलिवरवाटकिंस: मुझे यह लेख कमजोर लगा। मान लें कि वैरिएबल इंट का प्रकार था। यदि असंबद्ध छोड़ दिया जाता है तो मान 0 होगा और लेख का वादा नहीं होगा। तथ्य यह है कि स्ट्रिंग्स ऑब्जेक्ट हैं और इन्ट्स प्राइमिटिव हैं इस तथ्य के अप्रासंगिक हैं कि एक प्रोग्रामर एक चर को भूल सकता है। इस सवाल में हम केवल अशक्त स्ट्रिंग तुलनात्मक चीज़ को हल करते हैं।

— चेरोविम

तथ्य यह है कि @cherouvim intहै एक आदिम प्रकार है प्रासंगिक, के रूप में यह आह्वान करने के लिए असंभव है equalsएक पर intउपयोग करने के लिए मौसम चर्चा में कोई मतलब नहीं है, इसलिए, x.equals(constant)या constant.equals(x)के लिए intमान। और Integerमूल्यों के लिए, डिफ़ॉल्ट मान इसके nullबजाय है 0।

— होल्गर

Answer 6

यह ट्रिक v = nullटाइपो को रोकने के लिए माना जाता है ।

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

यह अभी भी C / C ++ कोड के लिए मूल्यवान ट्रिक है।

Answer 7

उसी कारण से आप इसे सी में करते हैं; असाइनमेंट एक अभिव्यक्ति है, इसलिए आप शाब्दिक को बाईं ओर रखते हैं ताकि अगर आप गलती से =इसके बजाय उपयोग करते हैं तो आप इसे अधिलेखित न कर सकें ==।

Comments

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

— स्कॉट स्मिथ

नहींं, जावा कंपाइलर उस प्रकार के टाइपो को पकड़ लेगा, जो भी आप पसंद करते हैं

— vava

@ जयजय - मुझे नहीं लगता कि प्रदर्शन से इसका कोई लेना-देना है। यह खतरनाक असाइनमेंट-इन-ए-सशर्त-अभिव्यक्ति की गलती से बचने के लिए सी में एक पुरानी चाल की तरह लगता है। विचार यह था कि यदि आप यह देखने के लिए जाँच करने का प्रयास कर रहे हैं कि क्या xसमान है 5, जब आप गलती से टाइप करते हैं if (x = 5), तो यह चुपचाप संकलन करेगा (और हमेशा मूल्यांकन करें true, भले ही इसके मूल्य की परवाह किए बिना x)। हालाँकि, यदि आप हमेशा शाब्दिक रूप से पहले निर्दिष्ट करने की आदत में आते हैं: 'अगर (5 = x)', तो कंपाइलर आपके काम की दोबारा जाँच कर सकता है और आपको डिबगर में सिर पीटने का समय बचा सकता है। आधुनिक संकलक इस आदत को अनावश्यक बनाते हैं।

— स्कॉट स्मिथ

-1: यदि आप गलती से उपयोग करते हैं = यह जावा में संकलित नहीं होगा; इसलिए C से कारण लागू नहीं होता है।

— जॉन स्कीट

तकनीकी रूप से अगर objटाइप java.lang.Boolean(बिग बी) का था, तो इससे फर्क पड़ सकता था (मुझे लगता है, वास्तव में कोशिश की गई या कुछ भी नहीं)।

— टॉम हॉल्टिन -

Answer 8

यह उन लोगों के लिए है जो बाईं ओर स्थिर रहना पसंद करते हैं। ज्यादातर मामलों में बायीं तरफ स्थिर रहने से NullPointerException को फेंकने (या एक और अशक्त होने) को रोका जा सकेगा। उदाहरण के लिए स्ट्रिंग विधि के बराबर भी एक शून्य जांच करता है। बाईं ओर स्थिर होने से, आपको अतिरिक्त जांच लिखने से रोक देगा। जो, दूसरे तरीके से भी बाद में किया जाता है। बाईं ओर शून्य मान होने से बस संगत हो रहा है।

पसंद:

 String b = null;
 "constant".equals(b);  // result to false
 b.equals("constant");  // NullPointerException
 b != null && b.equals("constant");  // result to false

Comments

NPE के इस छिपने से बगलों को और नीचे खोजने में मुश्किल होती है

— ओलिवर वाटकिंस

Answer 9

यह अलग तरीके से लिखने की योडा स्थिति है

जावा में

String myString = null;
if (myString.equals("foobar")) { /* ... */ } //Will give u null pointer

योदा की स्थिति

String myString = null;
if ("foobar".equals(myString)) { /* ... */ } // will be false 

Answer 10

निम्नलिखित कोड के साथ तुलना करें:

    String pingResult = "asd";
    long s = System.nanoTime ( );
    if ( null != pingResult )
    {
        System.out.println ( "null != pingResult" );
    }
    long e = System.nanoTime ( );
    System.out.println ( e - s );

    long s1 = System.nanoTime ( );
    if ( pingResult != null )
    {
        System.out.println ( "pingResult != null" );
    }
    long e1 = System.nanoTime ( );
    System.out.println ( e1 - s1 );

आउटपुट (कई निष्पादन के बाद):

null != pingResult
325737
pingResult != null
47027

इसलिए, pingResult != nullविजेता है।

Comments

एक अतिरिक्त लूप में अपना परीक्षण चलाएं! या बस IF स्टेटमेंट को स्विच करें। लंबी कहानी छोटी: कोई अंतर नहीं है! पहला लूप हमेशा धीमा होता है।

— मार्सेल जेस्सके

इस परीक्षण में, pingResult हमेशा गैर-अशक्त होता है। PingResult के समय का क्या होता है? मैं शर्त लगा रहा हूं कि यह प्लेटफ़ॉर्म स्वतंत्र है, लेकिन मेरे ओरेकल जावा 1.6 / लिनक्स स्टैक पर, परिणाम बहुत अधिक हैं (एक लूप में), सिवाय इसके कि अगर pingResult शून्य है, तो दोनों चेक कुछ प्रतिशत तेज हैं।

— ओगरे Psalm33

अगर आप "pingResult! = null block to null! = pingResult block डालते हैं, तो इससे" pingResult! = null 325737 "जैसा कुछ होगा

— सोला यांग

जैसा कि @ सोला यांग कहते हैं, अगर आप पिंगंडौल्ट लगाते हैं! = अशक्त होने से पहले, आप देखेंगे कि इसमें अशक्त होने में अधिक समय लगता है! = PingResult। अगर pingResult! = Null null से अधिक तेज़ था! = PingResult IDE (जैसे IntelliG, Eclipse, ...) डेवलपर्स को इस भूमिका का उपयोग करने के लिए बाध्य करने के लिए एक चेतावनी देगा;)

— adil.hilal

Answer 11

इसकी कम्यूटेटिव प्रॉपर्टी के कारण , object == nullऔर null == object( योदा संस्करण ) के बीच का एकमात्र अंतर संज्ञानात्मक प्रकृति का है : कोड को कैसे पढ़ा और पचाया जाता है। हालांकि मुझे इसका निश्चित उत्तर नहीं पता है, लेकिन मुझे पता है कि मैं व्यक्तिगत रूप से उस वस्तु की तुलना करना पसंद करता हूं जिसका मैं किसी और चीज से तुलना कर रहा हूं, बजाय इसके कि मैं जिस वस्तु का निरीक्षण कर रहा हूं, उसकी तुलना किसी और चीज से की जाए । विषय के साथ शुरू करें, फिर इसकी तुलना करने के लिए मूल्य।

कुछ अन्य भाषाओं में यह तुलना शैली अधिक उपयोगी है।

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