यदि / अन्यथा बयानों को मामलों की दुर्लभता या उनके साथ व्यवहार की कठिनाई द्वारा व्यवस्थित किया जाना चाहिए?

Question

कुछ कोड में मैं अभी लिख रहा हूँ, मेरे पास कुछ इस तरह है:

if (uncommon_condition) {
    do_something_simple();
} else {
    do();
    something();
    long();
    and();
    complicated();
}

मेरा एक भाग सोचता है "यह जिस तरह से लिखा गया है वह ठीक है। सरल मामलों को पहले जाना चाहिए और अधिक जटिल मामलों को आगे जाना चाहिए।" लेकिन एक अन्य हिस्सा कहता है: "नहीं! elseकोड के तहत जाना चाहिए if, क्योंकि ifअसामान्य मामलों elseसे निपटने के लिए है और अन्य सभी मामलों से निपटने के लिए है।" कौन सा सही या बेहतर है?

Comments

शर्तों की सादगी / समझ द्वारा आदेश! बाकी का अनुकूलन ऑप्टिमाइज़र, शाखा के भविष्यवक्ता और रिफैक्टिंग द्वारा किया जा सकता है।

— मार्जन वेंमा

यही कारण है कि हमें बड़ी रकम का भुगतान किया जाता है: इन कठिन निर्णयों को करने के लिए।

Answer 1

उनके निष्पादन की संभावना द्वारा आदेश। सबसे आम, सबसे अधिक संभावना है, आदि हालत (ओं) को पहले जाना चाहिए।

"उनके साथ काम करने में कठिनाई" को कोड संरचना, अमूर्तता आदि से निपटा जाना चाहिए, उदाहरण में अन्य ब्लॉक को एकल विधि कॉल के लिए फिर से जोड़ा जा सकता है। आप चाहते हैं कि आपकी ifधाराएँ समान स्तर पर हों।

if ( ! LotteryWinner ) {
    GoToWorkMonday();
} else {
    PlanYearLongVacation();
}

Comments

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

— मार्जन वेनमा

@MarjanVenema, मैं "नहीं" आईएनजी के बारे में आपकी बात देख सकता हूं। लेकिन डबल नकारात्मक वास्तविक "डब्ल्यूटीएफ" नहीं है। दूसरे दिन मैं हमारे कोड में इस में भाग गया doesNotAllowxxFiles = false। बहुत बुरा है लेकिन फिर ऐसा करेंif(! doesNotAllowxxFiles)

— राडारब

हां, डबल नकारात्मक, और / और / या (sic!) के साथ संयुक्त नकारात्मक और एक विधि / var के साथ संयुक्त नकारात्मक नाम में नहीं, हर बार एक मोड़ में मेरे मस्तिष्क को प्राप्त करें :-)

— मार्जन वेनेमा

अगर आप अपने आप को समझने में परेशानी महसूस कर रहे हैं कि क्या चल रहा है, तो मुझे लगता है कि यह अक्सर ऐसा करना उपयोगी होता है जैसे: simpleBool = ((complexBool || randomfFlag)) &&! randomFlag

— TruthOf42

मैं आपके साथ सहमत हूँ, गार्ड क्लॉज के अस्तित्व को छोड़कर (जो कि IF स्टेटमेंट के सामान्य भाग में असाधारण स्थिति है, सामान्य स्थिति नहीं है)।

— रॉबर्ट हार्वे

Answer 2

पठनीयता बढ़ाने का प्रयास करें। एक तरीका यह है कि लंबे कोड ब्लॉक को दूसरे हिस्से में रखें।

if (s == null)
     // short code
else 
     // long 
     // code
     // block

से अधिक पठनीय है

if (s != null)
    // long
    // code
    // block
else
    // short code

Comments

यह अधिक पठनीय क्यों है? मैं पठनीयता के संदर्भ में दोनों के बीच कोई अंतर नहीं देखता

— जॉन डेमेट्रियौ

@ जॉनडेमेट्रीउ द एल्स शॉर्ट है तो थिस दिखाई दे रहा है। लोग पहले संरचना के लिए स्कैन करते हैं, फिर उसे अर्थ प्रदान करते हैं। बिना एल्स के कोड एक के साथ कोड से अलग है, इसलिए एल्स को अधिक दृश्यमान बनाना अधिक समझ में आता है। (अन्य सभी चीजें बराबर हो रही हैं, मंगलवार को जब बारिश नहीं हो रही है, आदि)

Answer 3

कोई निश्चित नियम नहीं है जैसे कि मैंने उपयोग के बारे में सुना है लेकिन मैं इस तरह का पालन करता हूं

if(usual)
{
(more often)
}
else (unusual)
{
(rarely occurring)
}

लेकिन अगर दोनों के पास अलग-अलग गुणों के साथ एक ही कार्य है तो बेहतर है कि पहले असामान्य रूप से चलें, ताकि आप एक निर्देश बचा सकें।

---

if(x == 0)  // 1
  {x = 1;}  // 2
else
  {x = 2;}  // 3

उपरोक्त कोड के लिए विधानसभा कोड कुछ इस तरह होगा:

1. 000d 837DFC00        cmpl    $0, -4(%ebp)
   0011 7509            jne .L2

2. 0013 C745FC01        movl    $1, -4(%ebp)
   001a EB07            jmp .L3

    .L2:
3.001c C745FC02         movl    $2, -4(%ebp)

        .L3:

अगर अंदर की स्थिति सही है तो प्रवाह 1-> 2 (4 घुसपैठ) है
अगर अंदर की स्थिति झूठी है तो प्रवाह 1-> 3 (3 घुसपैठ) है

तो यह बेहतर है कि असामान्य या शायद ही कभी होने वाली घटनाओं को भाग और सामान्य स्थिति में रखें ताकि हम हर बार एक निर्देश बचा सकें;;

Answer 4

मैंने पाया है कि सटीक विपरीत पैटर्न से कोड को पढ़ने में आसानी होती है, और बयानों के दौरान नेस्टेड को कम या समाप्त कर देता है। मैं इसे "गौंटलेट" पैटर्न के रूप में संदर्भित करता हूं। (कहानी कहने में, एक गॉंटलेट चुनौतियों की एक श्रृंखला होगी, जिसे अंतिम कार्य पूरा होने से पहले सफलतापूर्वक पूरा करना होगा।) पहले अपने किनारे के मामलों को संभालने से , आप अपने कोड के मुख्य निकाय को साफ और संक्षिप्त करने की अनुमति देते हैं:

if(gauntlet_1){ handle the first gauntlet condition }; 
if(gauntlet_2){ handle the second gauntlet condition };
...
// All preconditions (gauntlets) have been successfully handled

// Perform your main task here

Comments

तो "हैंडल गौंटलेट" हिस्सा या तो नियंत्रण का हस्तांतरण होना होगा, जैसे फेंक या रिटर्न स्टेटमेंट, या वास्तव में गलती को ठीक करना होगा। कुछ लोग अगर ... रिटर्न स्टेटमेंट्स की एक श्रृंखला पर आते हैं, लेकिन मुझे नहीं लगता कि यह वास्तव में कोड को पढ़ना आसान बनाता है, जैसा कि आपने कहा।

यदि गॉंटलेट स्थिति कुछ ऐसी है जो फ़ंक्शन को सफल होने से रोकती है, तो यह तुरंत एक त्रुटि देता है। अगर गौंटलेट स्थिति को संभाला जा सकता है, तो मैं जब भी संभव हो कोड के मुख्य शरीर में प्रवेश करने से पहले ऐसा करता हूं। मैं मुख्य रूप से नेस्टेड IF स्टेटमेंट से बचने की कोशिश कर रहा हूं, जो मेरे अनुभव में अस्पष्ट त्रुटियों के प्रमुख कारणों में से एक है और कोडिंग त्रुटियों को डीबग करना कठिन है।

— बायरन जोन्स

Answer 5

मेरे लिए यह उन कोड की जटिलता से अधिक शर्तों के बारे में है जो वे निष्पादित करते हैं। आपको शर्तों को क्रमबद्ध करने की आवश्यकता है ताकि पहले असामान्य परिस्थितियों को फँसाया जा सके, फिर बाद में और अधिक सामान्य। इसके अलावा, यदि अन्य कोड वास्तव में लंबा और जटिल है, तो मैं शायद इसके लिए एक उप बनाऊंगा, ताकि पाठक के लिए सशर्त भाग स्पष्ट हो सके।

Answer 6

मेरे पास एक निश्चित नियम नहीं है, लेकिन आम तौर पर मैं इसका पालन करता हूं - सबसे पहले, विचार करें कि एक चूक डिजाइन पैटर्न कहां है जो इसे बाहर कर देगा। यदि नहीं, तो मैं इसे लिखता हूं ताकि अगर में स्थिति सबसे स्पष्ट रूप से समझ में आ जाए। यानी दोहरी नकारात्मकता और इस तरह से बचना।

Answer 7

ऐसे परिदृश्यों के लिए इसके लिए कोई अंगूठे का नियम नहीं है। लेकिन संभवतः हम if ब्लॉक में सकारात्मक या सबसे अधिक संभावना कोड लिखने के लिए और अन्य ब्लॉक या डिफ़ॉल्ट मामलों में छोड़ सकते हैं।

Comments

इससे पहले के उत्तर में बताई गई बातों पर कुछ भी पेश नहीं किया जाता है - प्रोग्रामर.स्टैकएक्सचेंज.

— com/a