कोडिंग शैली ... त्रुटि स्थिति पहले या आखिरी?

Question

आदेश के मामले में सामान्य में कौन सा बेहतर है? क्या आप गलती की स्थिति को ऊपर या नीचे रखते हैं?

if (noProblems == true) { 
    // do stuff 
} else { 
    // deal with problem 
} 

या

if (noProblems == false) { 
    // deal with problem 
} else { 
    // do stuff 
} 

Answer 1

मैं पहले त्रुटि मामलों को खत्म करने के लिए करना चाहते हैं - और जल्दी समारोह से लौटने ताकि 'खुश पथ' बनी हुई है अन-नेस्ट, उदा

if (some error condition) 
{ 
    //handle it 
    return; 
} 
//implicit else for happy path 
... 

अगर यह स्थिति खुश पथ के लिए अग्रणी पहचान करने के लिए आसान है, तो हर तरह से उस खंड प्रथम, डाल (धन्यवाद मार्सिन!)

Answer 2

अपने 1 या 2 लाइनों अगर और एक प्रारंभिक वापसी मैं इसे शीर्ष पर डालें - खासकर अगर यह समारोह की शुरुआत में है। जो लगभग एक अनुबंध की तरह पढ़ता है। अन्यथा, मैं "नकारात्मक से पहले सकारात्मक स्थिति" नियम के साथ जाता हूं।

Answer 3

यह आपके लिए स्पष्ट है पर निर्भर करता है। मेरा मतलब है, जो अधिक समझ में आता है, कि कोई समस्या का वास्तविक मूल्य नहीं है या उसके पास झूठा मूल्य है।

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

Answer 4

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

Answer 5

पहला मुझे थोड़ा बेहतर लगता है कि यह सशर्त में दोहरे नकारात्मक से बचाता है।

उसके अलावा, आप चीजों का निर्माण किया है, ताकि आप यह कर सकते हैं कि वास्तव में नहीं

// do stuff 

के बाद आप

// deal with problem 

तो परे है कि एक दूसरे के रूप में रूप में अच्छा लगता है।

Answer 6

के साथ कोशिश करें/पकड़ें मैं सामान्य प्रवाह करता हूं, और फिर अपवाद शर्तों को संभालता हूं।

इसका मतलब यह नहीं है कि त्रुटि जांच/स्क्रबिंग पहले नहीं होती है, लेकिन अगर मुझे विश्वास नहीं है कि मुझे क्या पारित किया गया है।

जैसे

if (foo is null) then 
    // bail 
end if 

if (bar == foo) then 
    // foo hasn't been changed... print the regular report 
else 
    // foo has changed, run the reconciliation report instead. 
end if 

मैं एक सीधी रेखा की तरह प्रवाह करने के लिए खुश कहानी पसंद है, और दुखी कहानी का अपना प्रेरणा पर बंद स्पिन।

Answer 7

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

"कोड पूरा, 2 संस्करण" खंड 15.1 से:

पहले सबसे आम मामलों डाल करके, आप अपवाद-मामला कोड किसी से निपटने की मात्रा को कम सामान्य मामलों को खोजने के लिए पढ़ने के लिए है। आप दक्षता में सुधार करते हैं क्योंकि आप सबसे आम मामलों को खोजने के लिए कोड की संख्या को कम करते हैं।

Answer 8

क्यों समारोह से एक निकास बिंदु नहीं बना सकते हैं और उचित सफाई वहाँ के बजाय कई रिटर्न होने करना ...

 

DWORD bRetVal= TRUE; 
if(foo is null) 
{ 
    bRetVal = FALSE; 
    goto Error; 
} 
else 
{ 
// do something 
} 

Exit: 
return bRetVal;