C# 8 - Nullable Reference Types

Microsoft C# 8 में Nullable Reference Types नामक एक नई सुविधा जोड़ रहा है। शुरुआत में, यह भ्रामक है क्योंकि सभी reference types nullable हैं… तो यह कैसे अलग है? आगे बढ़ते हुए, यदि सुविधा सक्षम है, तो reference types non-nullable हैं, जब तक कि आप स्पष्ट रूप से उन्हें nullable के रूप में नोट न करें।

मुझे समझाने दीजिए।

Nullable Reference Types

जब Nullable Reference Types सक्षम होते हैं और compiler को विश्वास होता है कि एक reference type null होने की संभावना है, तो यह आपको चेतावनी देता है। आप Visual Studio से चेतावनी संदेश देखेंगे:

और build चेतावनियां:

इस चेतावनी को हटाने के लिए, reference type के लिए एक प्रश्न चिह्न जोड़ें। उदाहरण के लिए:

public string StringTest()
{
    string? notNull = null;
    return notNull;
}

अब reference type C# 8 से पहले की तरह व्यवहार करता है।

यह सुविधा किसी भी C# फ़ाइल के शीर्ष पर <span class="inline-code"> #nullable enable </span> जोड़कर या .csproj फ़ाइल में <span class="inline-code">lt;NullableReferenceTypes&gt;true&lt;/NullableReferenceTypes&gt;</span> जोड़कर सक्षम की जाती है। बॉक्स से बाहर यह सक्षम नहीं है, जो एक अच्छी बात है क्योंकि यदि यह सक्षम था तो किसी भी मौजूदा code-base को क्रिसमस के पेड़ की तरह प्रकाशित होना चाहिए।

The Null Debate

Microsoft यह सुविधा अभी क्यों जोड़ रहा है? Nulls भाषा का हिस्सा रहे हैं, खैर शुरुआत से? ईमानदारी से, मुझे नहीं पता क्यों। मैंने हमेशा nulls का उपयोग किया है, यह C# में जीवन का एक तथ्य है। मुझे नहीं पता था कि nulls न होना एक विकल्प था… शायद nulls के बिना जीवन बेहतर होगा। हम पता लगाएंगे।

क्या आपको nulls का उपयोग करना चाहिए या नहीं? मैंने चल रही बहस को सारांशित किया है जैसा कि मैं समझता हूं।

के लिए

nulls के लिए तर्क आम तौर पर यह है कि एक object की एक अज्ञात स्थिति है। इस अज्ञात स्थिति को null के साथ दर्शाया जाता है। आप इसे SQL Server में bit data type के साथ देखते हैं, जिसमें 3 मान हैं, null (not set), 0 और 1। आप इसे UI में भी देखते हैं, जहां कभी-कभी यह जानना महत्वपूर्ण होता है कि क्या उपयोगकर्ता ने किसी फ़ील्ड को छुआ है या नहीं। कोई यह कह सकता है, “null के बजाय, एक अज्ञात स्थिति प्रकार या ‘not set’ स्थिति क्यों नहीं बनाते?” यह null से कैसे अलग है? आपको अभी भी इस अतिरिक्त स्थिति की जांच करनी होगी। अब आप प्रत्येक instance के लिए अज्ञात स्थितियां बना रहे हैं। null का उपयोग क्यों न करें और एक global अज्ञात स्थिति रखें?

विरुद्ध

nulls के खिलाफ तर्क यह है कि यह एक अलग data type है और आपको reference type का उपयोग करने के लिए हर बार इसकी जांच करनी होगी। शुद्ध परिणाम इस तरह का कोड है:

var user = GetUser(username, password);

if(user != null)
{
    DoSomethingWithUser(user);
} else 
{
    SetUserNotFoundErrorMessage()
}

यदि GetUser method सभी cases में एक user return करता है, जिसमें जब user नहीं मिलता है। यदि कोड कभी null return नहीं करता है, तो इसके खिलाफ guard करना एक बर्बादी है और आदर्श रूप से, यह कोड को सरल बनाता है। हालांकि, किसी बिंदु पर, आपको एक empty user की जांच करनी होगी और एक error message प्रदर्शित करनी होगी। null का उपयोग न करने से user not found के business case को भरने की आवश्यकता नहीं हटती है।

क्या यह सुविधा एक अच्छा विचार है?

इस सुविधा का उद्देश्य nulls के उपयोग को समाप्त करना नहीं है, बल्कि इसके बजाय सवाल पूछना है: “क्या कोई बेहतर तरीका है?” और कभी-कभी जवाब “नहीं” है। यदि हम थोड़े से सोच-विचार के साथ nulls की constant checking को समाप्त कर सकते हैं, जो बदले में हमारे कोड को सरल बनाता है। मैं अंदर हूं। अच्छी खबर यह है कि C# ने nulls के साथ काम करना trivial बना दिया है।

मुझे डर है कि कुछ एक dogmatic stance लेंगे और एक system के नुकसान के लिए nulls को समाप्त करने पर जोर देंगे। यह एक fool’s errand है, क्योंकि nulls C# के लिए integral हैं।

क्या Nullable Reference Types एक अच्छा विचार है? यह है, यदि अंतिम परिणाम सरल और कम error prone code है।