मैं एक पुस्तक पढ़ रहा हूं जो दावा करता है (पन इरादा) "आपको Debug.Assert विधियों के साथ अपना कोड लोड करना चाहिए जहां भी आपके पास ऐसी स्थिति हो जो हमेशा सत्य या गलत होगी।"डीबग.एएसएसर्ट और डीबग.फेल को उदारतापूर्वक इस्तेमाल किया जाना चाहिए, और उन्हें उत्पादन कोड में छोड़ा जाना चाहिए?
मैं इन दो डीबग विधियों का उपयोग नहीं कर रहा हूं, लेकिन यह कुछ समझ में आता है। हालांकि, मैं अपने उत्पादन कोड अड्डों में इस सामान को भरने के लिए नाराज हूं।
विचार?
यह ठीक है, क्योंकि संकलक रिलीज निर्माण में इसे छोड़ देता है। यह बुरा अभ्यास नहीं है, और आपको उन्हें स्रोत से हटाने की आवश्यकता नहीं है (वास्तव में, आपको शायद नहीं करना चाहिए)। लेकिन तुम सावधान रहना चाहिए:
Debug.Assert(SomethingImportantThatMustExecute());
है बुरा - SomethingImportantThatMustExecute रिलीज में नजरअंदाज कर दिया जाएगा; आपको इसका उपयोग करना होगा:
bool result = SomethingImportantThatMustExecute()
Debug.Assert(result);
असल में, सशर्त तरीकों और आंशिक तरीकों से कॉल में दुष्प्रभावों से बचें।
यदि आप रिलीज बिल्ड (विजुअल स्टूडियो प्रोजेक्ट सेटिंग का उपयोग करके) संकलित करते हैं, तो सभी Debug.Assert कथन स्वचालित रूप से हटा दिए जाएंगे। तो हाँ, उदारतापूर्वक उनका इस्तेमाल करें।
आप उत्पादन कोड अड्डों में उदारता से Debug.Assert का उपयोग कर सकते हैं। Debug.AssertConditionalAttribute से सजाया गया है। यदि आप अपने कोड को "रीलीज" कॉन्फ़िगरेशन में संकलित करते हैं, तो संकलक Debug.Assert पर कॉल छोड़ देगा।
यह इस बात पर निर्भर करता है कि आप इसका क्या उपयोग कर रहे हैं। यदि आप इसे अपने तरीके से सम्मिलित करने के लिए उपयोग कर रहे हैं, यह सुनिश्चित करने के लिए कि वे ठीक से काम कर रहे हैं, मुझे लगता है कि यह ठीक है - लेकिन मैं यूनिट परीक्षणों को प्राथमिकता देना चाहता हूं ताकि मैं जो कुछ भी संभव हो, उसके बारे में सोच सकूं।
यह आने वाले इनपुट को सत्यापित करने के लिए इसका उपयोग करने के लिए एक अच्छा विचार (आईएमओ) नहीं है - उदा। मापदंडों। उस मामले में मेरा मानना है कि इसके बारे में सामान्य तरीके से अपवाद उपयोग करने के लिए और अधिक सुसंगत है:
if (foo == null)
{
throw new ArgumentNullException("foo");
}
मेरे विचार इस व्यवहार नहीं परिवर्तन सिर्फ इसलिए कि आप रिहाई कोड चला रहे हैं चाहिए।
हां, दावे ठीक हैं। और ध्यान दें कि वे न केवल तर्क-जांच (यह स्पष्ट है) बल्कि दस्तावेजों के रूप में भी काम करते हैं, टिप्पणियों से अधिक विश्वसनीय।
लेकिन यूनिट-परीक्षण के बारे में पहले से सोचें। यदि आप डीबग का परीक्षण करने जा रहे हैं तो परिणाम (त्रुटि तर्क के संबंध में) आपके रिलीज़ संस्करण से अलग हो सकते हैं।
रिलीज बिल्ड में आप सक्रिय होना चाहते हैं चेक के लिए आप Trace.Assert() का उपयोग कर सकते हैं।
और किसी ने भी Code Contracts का उल्लेख नहीं किया है, जो आपके कोड की जांच और दस्तावेज़ीकरण का एक समृद्ध और अधिक संरचित तरीका है।
1+ – Marcel
मुझे पता है कि यह उन्हें हटा देगा (यह सभी प्रतीकों को हटा देता है), लेकिन मुझे आश्चर्य है कि यह बदसूरत या बुरी आदत है या नहीं। मैं आपके उत्तर से मानता हूं कि यह नहीं है। – richard
@ रिचर्ड DesLonde: वास्तव में, यह अच्छा अभ्यास है, जब तक यह आपको अच्छा कोड विकसित करने में मदद करता है। कोड अनुबंधों का उल्लेख करने के लिए –