FxCop क्यों फ़ील्ड को डिफ़ॉल्ट मान पर प्रारंभ करना गलत लगता है?

Question

जब एक क्षेत्र (यहाँ एक bool करने के लिए गलत) करने के लिए डिफ़ॉल्ट डिफ़ॉल्ट-मान निर्दिष्ट, FxCop का कहना है:

Resolution : "'Bar.Bar()' initializes field 'Bar.foo' 
       of type 'bool' to false. Remove this initialization 
       because it will be done automatically by the runtime." 

अब, मैं int a = 0 या bool ok = false के रूप में है कि कोड कुछ अतिरेक पेश कर रहा है पता है, लेकिन मेरे लिए यह लगता है एक बहुत ही अच्छा कोड-अभ्यास, एक ऐसा जो कि मेरे शिक्षकों ने मेरी राय में ईमानदारी से जोर दिया।

न केवल प्रदर्शन जुर्माना बहुत कम है, अधिक महत्वपूर्ण बात यह है कि डिफ़ॉल्ट पर भरोसा करते हुए प्रत्येक प्रोग्रामर के ज्ञान पर डिफ़ॉल्ट रूप से आने वाले प्रत्येक डेटाटाइप पर कोड के टुकड़े का उपयोग करने के लिए भरोसा किया जाता है। (डेटटाइम?)

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

क्या FxCop यहां एक स्पष्ट गलती कर रहा है, या इसके लिए और भी कुछ है?

दो अपडेट:

1. यह सिर्फ मेरी राय है, लेकिन क्या मैं विश्वविद्यालय (बेल्जियम) में सिखाया गया है नहीं है। ऐसा नहीं है कि मैं argumentum ad verecundiam का उपयोग करना चाहता हूं, लेकिन यह दिखाने के लिए कि यह सिर्फ मेरी राय नहीं है। और के विषय में है कि:

2. मेरे क्षमायाचना, मैं सिर्फ इस एक पाया:

   Should I always/ever/never initialize object fields to default values?

Answer 1

वहाँ कुछ मामलों में, इस से महत्वपूर्ण प्रदर्शन लाभ हो सकता है। विवरण के लिए, see this CodeProject article.

मुख्य मुद्दा यह है कि यह सी # में अनावश्यक है। सी ++ में, चीजें अलग होती हैं, इसलिए कई प्रोफेसर सिखाते हैं कि आपको हमेशा प्रारंभ करना चाहिए। वस्तुओं को शुरू करने के तरीके को .NET में बदल दिया गया है।

.NET में, वस्तुओं को हमेशा बनाए जाने पर प्रारंभ किया जाता है। यदि आप प्रारंभकर्ता जोड़ते हैं, तो यह संभव है (सामान्य) कि आप अपने चर के दोहरा प्रारंभिक कारण बनते हैं। ऐसा होता है कि क्या आप उन्हें कन्स्ट्रक्टर या इनलाइन में प्रारंभ करते हैं।

इसके अतिरिक्त, प्रारंभिक होने के बाद .NET में अनावश्यक है (यह हमेशा होता है, भले ही आप डिफ़ॉल्ट रूप से प्रारंभ करने के लिए स्पष्ट रूप से नहीं कहें), एक प्रारंभिकता जोड़ना, एक पठनीयता दृष्टिकोण से, जो आप जोड़ने की कोशिश कर रहे हैं कोड जिसमें एक समारोह है। कोड के प्रत्येक टुकड़े का उद्देश्य होना चाहिए, या अनावश्यक होने पर हटा दिया जाना चाहिए। "अतिरिक्त" कोड, भले ही यह हानिरहित था, सुझाव देता है कि यह एक कारण के लिए है, जो रखरखाव को कम करता है।

Answer 2

यह किसी भी समय स्थानीय रूप से परिभाषित "कॉर्पोरेट मानक" को जानने वाले हर प्रोग्रामर पर निर्भर नहीं है जो किसी भी समय बदल सकता है, लेकिन मानक रूप से मानक में परिभाषित कुछ पर। आप यह भी कह सकते हैं "x++ का उपयोग न करें क्योंकि यह प्रत्येक प्रोग्रामर के ज्ञान पर निर्भर करता है।

Answer 3

आपको याद रखना होगा कि FxCop नियम केवल दिशानिर्देश हैं, वे अटूट नहीं हैं। यह भी कहते हैं तो नियम आप का उल्लेख के विवरण के लिए पेज (http://msdn.microsoft.com/en-us/library/ms182274(VS.80).aspx, जोर मेरा) पर:

जब चेतावनी को निकालना है:

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

अब, नियम पूरी तरह गलत नहीं है, लेकिन जैसा कि यह कहता है, यह आपके लिए प्राथमिकता नहीं है, इसलिए नियम को अक्षम करें।

Answer 4

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

ऐसा ही एक समस्या हम मुठभेड़ है, प्रलेखन कारणों से हम इस

/// <summary> 
/// a test class 
/// </summary> 
/// <remarks>Documented on 4/8/2009 by richard</remarks> 
public class TestClass 
{ 
    /// <summary> 
    /// Initializes a new instance of the <see cref="TestClass"/> class. 
    /// </summary> 
    /// <remarks>Documented on 4/8/2009 by Bob</remarks> 
    public TestClass() 
    { 
     //empty constructor 
    }   
} 

संकलक स्वचालित रूप से इस निर्माता बनाता है की तरह एक खाली निर्माता बना सकते हैं, FX पुलिस में शिकायत लेकिन हमारे सैंडकैसल प्रलेखन नियमों के सभी सार्वजनिक तरीकों की आवश्यकता होती है तो दस्तावेज किया जाना चाहिए, इसलिए हमने केवल एफएक्स पुलिस को बताया कि इसके बारे में शिकायत न करें।

Answer 5

FxCop को सभी के लिए नियम प्रदान करना है, इसलिए यदि यह नियम आपको अपील नहीं करता है, तो बस इसे बाहर कर दें।

अब, मैं सुझाव दूंगा कि यदि आप स्पष्ट रूप से डिफ़ॉल्ट मान घोषित करना चाहते हैं, तो इसे करने के लिए निरंतर (या स्थैतिक रीडोनली चर) का उपयोग करें। यह मूल्य के साथ शुरू करने से भी स्पष्ट होगा, और FXCop शिकायत नहीं करेगा।

private const int DEFAULT_AGE = 0; 

private int age = 0; // FXCop complains 
private int age = DEFAULT_AGE; // FXCop is happy 

private static readonly DateTime DEFAULT_BIRTH_DATE = default(DateTime); 

private DateTime birthDate = default(DateTime); // FXCop doesn't complain, but it isn't as readable as below 
private DateTime birthDate = DEFAULT_BIRTH_DATE; // Everyone's happy 

Answer 6

Reed Copsey said क्षेत्रों प्रभावों प्रदर्शन के लिए डिफ़ॉल्ट मान को निर्दिष्ट, और वह a test from 2005 को दर्शाता है।

public class A 
{ 
    // Use CLR's default value 
    private int varA; 
    private string varB; 
    private DataSet varC; 
} 

public class B 
{ 
    // Specify default value explicitly 
    private int varA = 0; 
    private string varB = null; 
    private DataSet varC = null; 
} 

अब आठ साल और सी # और .NET के चार संस्करण बाद में मैं .NET फ्रेमवर्क 4.5 और सी # 5, डिफ़ॉल्ट अनुकूलन के साथ रिलीज के रूप में संकलित के तहत है कि परीक्षण दोहराने के लिए दृश्य स्टूडियो 2012 का उपयोग कर रहा देख कर हैरान था फैसला किया कि उनके डिफ़ॉल्ट मानों के साथ फ़ील्ड को स्पष्ट रूप से प्रारंभ करने और डिफ़ॉल्ट मान निर्दिष्ट नहीं करने के बीच अभी भी एक प्रदर्शन अंतर है। मैं बाद में सी # कंपाइलर्स को उन निरंतर असाइनमेंट को ऑप्टिमाइज़ करने की अपेक्षा करता था।

 
No init: 512,75 Init on Def: 536,96 Init in Const: 720,50 
Method No init: 140,11 Method Init on Def: 166,86 

^{(the rest)}

तो मैं वर्गों A और इस परीक्षण में B की कंस्ट्रक्टर्स अंदर peeked, और दोनों खाली हैं:

.method public hidebysig specialname rtspecialname 
    instance void .ctor() cil managed 
{ 
    // Code size 7 (0x7) 
    .maxstack 8 

    IL_0000: ldarg.0 
    IL_0001: call instance void [mscorlib]System.Object::.ctor() 
    IL_0006: ret 
} // end of method .ctor 

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

तो, परीक्षण गलत होना चाहिए ... मैंने वर्गों की सामग्री को A और B की सामग्री बदल दी, परिणाम स्ट्रिंग में संख्याओं को बदल दिया, और परीक्षणों को फिर से चलाया। और लो और देखें अब अचानक डिफ़ॉल्ट मान निर्दिष्ट करना है।

 
No init: 474,75 Init on Def: 464,42 Init in Const: 715,49 
Method No init: 141,60 Method Init on Def: 171,78 

^{(the rest)}

इसलिए मैं निष्कर्ष है कि सी # संकलक सही ढंग से इस मामले में जहां आप क्षेत्रों के लिए डिफ़ॉल्ट मान निर्दिष्ट के लिए अनुकूलित करता है। इससे कोई प्रदर्शन अंतर नहीं होता है!

---

अब हम जानते हैं कि प्रदर्शन वास्तव में नहीं एक मुद्दा है। और मैं Reed Copsey's statement से असहमत "'अतिरिक्त' कोड, भले ही यह हानिरहित था, चलता है कि यह एक कारण है, जो रख-रखाव की कम कर देता है के लिए है।" और Anders Hansson इस पर सहमत:

दीर्घकालिक सोचो रखरखाव।

• कोड को यथासंभव स्पष्ट रखें।
• यदि आपको ऐसा करने की आवश्यकता नहीं है तो आरंभ करने के लिए भाषा विशिष्ट तरीकों पर भरोसा न करें। शायद भाषा का एक नया संस्करण अलग-अलग काम करेगा?
• भविष्य प्रोग्रामर आपको धन्यवाद देंगे।
• प्रबंधन आपको धन्यवाद देगा।
• चीजों को थोड़ी सी भी परेशान क्यों करें?

भविष्य के रखरखाव एक अलग पृष्ठभूमि से आ सकते हैं। यह वास्तव में "सही" के बारे में नहीं है, यह लंबे समय तक सबसे आसान होगा।