2011-01-23 8 views
23

क्या यह कोड वास्तव में एक अच्छा अभ्यास है जिससे आपके कोड को बेहतर पठनीय बनाने के लिए आईएफ स्थितियों में नहीं ऑपरेटर का उपयोग करने से बचें? मैंने सुना है कि if (doSomething()) बेहतर है तो if (!doSomething()).आईएफ स्थितियों में ऑपरेटर का उपयोग नहीं

+2

के साथ एक ही है जैसे की कोशिश "' अगर (...) '' अगर (! ...) 'से बेहतर है"? – delnan

+0

प्रश्न इसे और स्पष्ट करने के लिए थोड़ा बढ़ा दिया गया है। – Eugene

+0

मेरे लिए नहीं एक के तथ्य एक और की तुलना में बेहतर है, बस आप का उपयोग करना चाहिए जो हर स्थिति में उपयुक्त हो, सशर्त दुनिया बहुत व्यापक और विविध है। –

उत्तर

32

यह वास्तव में उस पर निर्भर करता है जिसे आप पूरा करने की कोशिश कर रहे हैं। यदि आपके पास कोई और खंड नहीं है तो if(!doSomething()) ठीक लगता है। हालांकि, अगर आप

if(!doSomething()) { 
    ... 
} 
else { 
    // do something else 
} 

है मैं शायद उस तर्क ! ऑपरेटर को हटाने और if खंड थोड़ा और अधिक स्पष्ट बनाने के लिए रिवर्स चाहते हैं।

+0

+1 बहुत सच है कि में कुछ नहीं कर रहे हैं। –

+1

मैं (लगभग) हमेशा elses संरचना करता हूं ताकि निष्पादन की सबसे आम शाखा पहले आती है। – Dunes

+1

इस जांच करने के लिए PMD नियम ConfusingTernary है: http://pmd.sourceforge.net/pmd-5.0.3/rules/java/design.html#ConfusingTernary –

11

नहीं, if..then..else कथन में ! ऑपरेटर का उपयोग करने में बिल्कुल कुछ भी गलत नहीं है।

चर के नामकरण, और आपके उदाहरण में, विधियां महत्वपूर्ण हैं। यदि आप उपयोग कर रहे हैं:

if(!isPerson()) { ... } // Nothing wrong with this 

हालांकि:

if(!balloons()) { ... } // method is named badly 

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

0

मैंने कभी इस बारे में कभी नहीं सुना।

कैसे

if (doSomething()) { 
} else { 
    // blah 
} 

से

if (!doSomething()) { 
    // blah 
} 

बेहतर है बाद में अधिक स्पष्ट और संक्षिप्त है।

इसके अलावा! ऑपरेटर जटिल परिस्थितियों में दिखाई दे सकता है जैसे कि (! ए || बी)। तब आप इससे कैसे बचते हैं?

का उपयोग करें! ऑपरेटर जब आपको चाहिए।

+1

आप एक शर्त – Mikey

19

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

if ((a.b && c.d.e) || !f) 

देखो तुम जैसे

bool isOk = a.b; 
bool isStillOk = c.d.e 
bool alternateOk = !f 

कुछ करना चाहते हो सकता है है तो अपने अगर बयान

if ((isOk && isStillOk) || alternateOk) 

करने के लिए सरल है यह सिर्फ कोड अधिक पठनीय बनाता है। और यदि आपको डीबग करना है, तो आप दायरे में चर के माध्यम से खोदने के बजाय vars के isOk सेट को डीबग कर सकते हैं। एनपीई से निपटने के लिए यह भी मददगार है - सरल भाग में कोड तोड़ना हमेशा अच्छा होता है।

1

आमतौर पर यह बुरा विचार नहीं है! -ऑपरेटर यदि आपके पास विकल्प है। एक साधारण कारण यह है कि यह त्रुटियों का स्रोत हो सकता है, क्योंकि इसे अनदेखा करना संभव है। अधिक पठनीय हो सकता है: यदि कुछ मामलों में (conditionA == false)। यदि आप अन्य भाग को छोड़ देते हैं तो यह मुख्य रूप से एक भूमिका निभाता है। यदि आपके पास कोई अन्य-ब्लॉक है तो आपको स्थिति में अस्वीकृति का उपयोग नहीं करना चाहिए।

इस तरह से बना-स्थिति को छोड़कर:

if(!isA() && isB() && !isNotC()) 

यहाँ आप निषेध किसी प्रकार का उपयोग करने के लिए वांछित तर्क निकलना है। इस मामले में, क्या वास्तव में के बारे में सोच के लायक है कार्य या चर का नामकरण है। उन्हें नाम देने का प्रयास करें ताकि आप उन्हें बिना किसी निषेध के सरल परिस्थितियों में उपयोग कर सकें।

इस मामले आप isNotC() के तर्क के बारे में सोचना चाहिए और यह एक तरीका है आईएससी() अगर यह समझ में आता है द्वारा प्रतिस्थापित किया जा सकता है।

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

4

सामान्य में,! एक पूरी तरह से अच्छा और पठनीय बुलियन तर्क ऑपरेटर है। इसका उपयोग करने का कोई कारण नहीं है जब तक कि आप डबल नकारात्मक को हटाकर या मॉर्गन के कानून को लागू करके सरल बना रहे हों।

!(!A) = A 

या

!(!A | !B) = A & B 

एक सामान्य नियम के रूप में, अपने बूलियन वापसी तरीकों स्मरक के हस्ताक्षर रखने के लिए और सम्मेलन के साथ कतार में। परिदृश्य के साथ समस्या जो @ hvgotcodes का प्रस्ताव है कि निश्चित रूप से a.b और c.d.e के साथ शुरू करने के लिए बहुत दोस्ताना उदाहरण नहीं हैं। मान लीजिए कि आपके पास उड़ान बुकिंग आवेदन के लिए उड़ान और सीट कक्षा है। फिर एक उड़ान बुकिंग के लिए शर्त पूरी तरह से

if(flight.isActive() && !seat.isTaken()) 
{ 
    //book the seat 
} 

यह पूरी तरह से पठनीय और समझने योग्य कोड हो सकती है। आप सीट क्लास के लिए अपने बूलियन तर्क को दोबारा परिभाषित कर सकते हैं और इस स्थिति को फिर से लिख सकते हैं।

if(flight.isActive() && seat.isVacant()) 
{ 
    //book the seat 
} 

इस प्रकार हटा रहा है! ऑपरेटर अगर यह वास्तव में आपको परेशान करता है, लेकिन आप देखेंगे कि यह सब आपके बूलियन विधियों के अर्थ पर निर्भर करता है। रुको, वाट -

1

इस

if (!(a | b)) { 
    //blahblah 
} 

यह

if (a | b) {} 
else { 
    // blahblah 
} 
संबंधित मुद्दे