सी # कोड के लिए ReSharper उलटा IFs क्यों करता है? क्या यह बेहतर प्रदर्शन (यहां तक ​​कि थोड़ा) देता है?

Question

निम्नलिखित कोड नमूना पर विचार करें:

private void AddEnvelope(MailMessage mail) 
{ 
    if (this.CopyEnvelope) 
    { 
     // Perform a few operations 
    } 
} 

बनाम

private void AddEnvelope(MailMessage mail) 
{ 
    if (!this.CopyEnvelope) return; 
    // Perform a few operations 
} 

क्या नीचे कोड किसी भी तेजी से निष्पादित करेगा? Xzx26 यह सिफारिश क्यों करेगा?

अद्यतन

इस प्रश्न के बारे में सोचना जवाब कुछ लोगों के लिए स्पष्ट प्रतीत हो सकता है। लेकिन हम में से बहुत से डेवलपर्स पहले स्थान पर if कथन के घोंसले के घोंसले की आदत में कभी नहीं थे ...

Answer 1

अपडेट किया गया उत्तर:

यह एक कोड रख-रखाव सुझाव है। एक आईएफ स्टेटमेंट में शेष कोड को घोंसले से पढ़ने के लिए आसान है। उदाहरण/इस की चर्चा निम्न लिंक पर देखा जा सकता:

:

• Flattening Arrow Code
• Replace Nested Conditional With Guard Clauses
• Code Contracts अनुभाग

मूल उत्तर "विरासत वक्तव्य आवश्यक है"

यह वास्तव में चला जाएगा (बहुत लापरवाही से) निष्पादन करने से धीमा नहीं है।

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

Answer 2

इससे कोई फर्क नहीं पड़ता। उन प्रदर्शन समस्याओं पर परेशान करना बंद करें जो मौजूद नहीं हैं - अपने कोड के उन क्षेत्रों की पहचान करने के लिए एक प्रोफाइलर का उपयोग करें जो मुद्दों को प्रदर्शित करते हैं, और उन्हें ठीक करते हैं। प्रोएक्टिव ऑप्टिमाइज़ेशन - इससे पहले कि आप जानते हों कि कोई समस्या है - परिभाषा के अनुसार समय की बर्बादी है।

Answer 3

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

Answer 4

यह एक सशर्त का एक रिफैक्टर है जिसमें पूरे विधि सामग्री को Guard Clause पर शामिल किया गया है। अनुकूलन के साथ इसका कोई लेना-देना नहीं है।

Answer 5

मुझे इस तरह की चीजों को अनुकूलित करने के बारे में टिप्पणियां पसंद हैं, इसे थोड़ा और जोड़ने के लिए ...

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

if (ThisOneUsuallyPasses() && ThisOneUsuallyFails()) 

रूप

if (ThisOneUsuallyFails() && ThisOneUsuallyPasses()) 

तो अच्छा है क्योंकि यह केवल अजीब मामला है कि पहले एक वास्तव में काम करता है आप दूसरे को देखने के लिए है पर है नहीं है। इसके कुछ अन्य स्वाद हैं जो आप प्राप्त कर सकते हैं, लेकिन मुझे लगता है कि आपको बिंदु प्राप्त करना चाहिए।

स्ट्रिंग, संग्रह, आपके डेटाबेस को इंडेक्स करने और ऑब्जेक्ट आवंटित करने के बारे में चिंता करने के लिए बेहतर है, यदि आप पर्फ के बारे में चिंता कर रहे हैं तो बयान के बारे में चिंता करने में बहुत समय व्यतीत करें।

सामान्यतः, आप जो निचला कोड देते हैं, वह आपको एक कथन के अंदर कोड के विशाल ब्लॉक से बचने का मौका देता है जो मूर्खतापूर्ण टाइपो संचालित त्रुटियों का कारण बन सकता है। पुरानी स्कूल सोच यह थी कि आपको केवल एक बिंदु होना चाहिए कि आप कोडर त्रुटि की एक अलग नस्ल से बचने के लिए एक विधि से वापस आएं। वर्तमान सोच (कम से कम कुछ उपकरण विक्रेताओं जैसे जेटब्रेन रिशेर्पर, आदि) ऐसा लगता है कि सशर्त बयान के अंदर कम से कम कोड को लपेटना बेहतर है। उससे कहीं ज्यादा कुछ व्यक्तिपरक होगा इसलिए मैं इसे छोड़ दूंगा।

Answer 6

आवश्यक पढ़ने: Cyclomatic_complexity

cyclomatic जटिलता एक कार्यक्रम के स्रोत कोड

जिसका मतलब है के माध्यम से रैखिक स्वतंत्र रास्तों की संख्या का एक मात्रात्मक मापन, हर बार जब आप का उपयोग कर शाखा और if बयान है आप साइक्लोमैटिक कॉम्प्लेक्सिटी को 1.

प्रत्येक का परीक्षण करने के लिए बढ़ाएं कार्यक्रम के माध्यम से रैखिक रूप से स्वतंत्र मार्ग; इस मामले में, परीक्षण मामलों की संख्या कार्यक्रम की चक्रीय जटिलता के बराबर होगी।

जिसका अर्थ है, यदि आप प्रत्येक कोड को पूरी तरह से जांचना चाहते हैं, तो प्रत्येक if कथन के लिए आपको एक नया परीक्षण केस पेश करना होगा।

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

if कथनों को हटाकर, आपकी कोड जटिलता कम हो जाती है क्योंकि परीक्षण के लिए आवश्यक परीक्षण मामलों की संख्या कम होती है।