क्या किसी तकनीकी कारण का उपयोग करने के लिए या सी # में var का उपयोग नहीं करने के लिए कोई तकनीकी कारण है?

Question

ऐसा लगता है कि अधिक से अधिक सी # कोड मैंने पढ़ा वर प्रकार पहचानकर्ता का उपयोग करता है:

foreach (var itemChange in ItemChanges) 
{ 
    //... 
} 

बजाय

स्पष्ट प्रकार कहा:

foreach (ItemChange itemChange in ItemChanges) 
{ 
    //... 
} 

प्रकार में जाना जाता है, तब भी जब।

मैं अभी भी बाद में स्पष्ट संस्करण का उपयोग कर रहा हूं क्योंकि मुझे लगता है कि बाद में इसे पढ़ने वाला कोई व्यक्ति जल्दी से समझ जाएगा कि यदि आप var का उपयोग करते हैं तो एक प्रकार का चर है।

लेकिन क्या कोई तकनीकी एक या दूसरे का उपयोग करने का कारण है?

Answer 1

नहीं, बस पठनीयता।

Answer 2

कोई तकनीकी कारण नहीं है। यदि संकलन समय पर प्रकार का अनुमान नहीं लगाया जा सकता है तो कोड संकलित नहीं होगा।

आप यह कहने में सही हैं कि ऐसे उदाहरण हैं जहां रीडबिलिटी के लिए एक स्पष्ट प्रकार का उपयोग करना बेहतर हो सकता है, उदा।

var obj = SomeMethod(); // what's the type? you'd have to inspect SomeMethod() 
SomeClass obj = SomeMethod(); // the type is obvious 

लेकिन अन्य उदाहरण जहां var का उपयोग पूर्ण ज्ञान बनाता है, उदा।

var obj = new SomeClass(); // the type is obvious 
SomeClass obj = new SomeClass(); // the duplication of type is unnecessary 

Answer 3

नहीं। var का उपयोग करें जहां यह पठनीयता और इसके विपरीत में सुधार करता है।

Answer 4

var एक सी # 3.x + सुविधा है, है ना? इसका उपयोग किए बिना, आपका कोड अन्य संस्करणों के साथ भी अधिक संगत है।

और ऐसा में दिलचस्प सवाल है, जब आप खोज "var C#"

Answer 5

सामान्य कोई तकनीकी कारण में आता है। पठनीयता - किसी भी दिशा में - एकमात्र वास्तविक कारक है।

हालांकि, एक छोटी सी चेतावनी यह है कि varस्थिर चर का प्रकार अनुमानित करेगा। यदि आप एक उप या सुपर क्लास प्रकार चाहते हैं तो आपको स्वयं कास्टिंग करने की आवश्यकता होगी। foreach के मामले में, जैसा कि आपके उदाहरण में है, आप आमतौर पर उप-वर्ग प्रकार के साथ अपने लूप वैरिएबल को घोषित करके "मुक्त" के लिए डाउनकास्टिंग कर सकते हैं।

क्लासिक उदाहरण एक एक्सएमएल NodeList कि आप जानते हैं से अधिक पुनरावृत्ति है XmlElement की एक सूची है, लेकिन NodelistXmlNode रों का एक संग्रह के रूप में लिखा गया हो। बेशक आप अपने इच्छित प्रकार को वापस पाने के लिए एक कास्ट या as का उपयोग कर सकते हैं, लेकिन यह टाइप अनुमान का उपयोग करने के उद्देश्य को हराने के लिए प्रतीत होता है :-)

बेशक, संकलक आपको जल्द ही इसके बारे में बताएगा जैसा कि आप नोड के सदस्य का उपयोग करने का प्रयास करते हैं जो केवल XmlElement पर उपलब्ध है - इसलिए यह अभी भी एक तकनीकी अंतर नहीं है।

---

एक और बात यह है कि एक छोटे से परेशान है कि अगर आप Resharper जैसे उपकरण भी, तो यह आपको हर संभव स्थिति में var का उपयोग का सुझाव के बारे में बहुत आक्रामक है। यह विशेष रूप से परेशान होता है जब यह आपको बदलने की सिफारिश करता है, उदाहरण के लिए, intvar में घोषणा!

हालांकि, जब तक कि आप उस सुविधा को बंद नहीं करते हैं, तब तक आप Resharper से कम "शोर" प्राप्त करेंगे जितना अधिक आप var का उपयोग करेंगे।

Answer 6

मुझे पता है कि एकमात्र तकनीकी कारण यह है कि आप var के बिना निहित कास्ट कर सकते हैं, उदा।

int i = 5; 
double a = i; // implicit cast with explicit types 

लेकिन यहां मैं var पसंद करता हूं क्योंकि यह स्पष्ट रूप से कलाकार बनाता है;

var a = (double)i; // explicit cast with implicit types 

लेकिन वास्तव में सामान्य कारण पठनीयता है, जैसा कि आप ने कहा: मैं प्रकार मैं देखभाल करते हैं जब मैं एक प्रतिनिधित्व बदलते जैसे रूपांतरण प्रदर्शन कर रहा हूँ के बारे में इतना परवाह नहीं है, जबकि। आपको खुद से पूछने के लिए सवाल यह है कि आपको लगता है कि पठनीयता के लिए सटीक ठोस प्रकार महत्वपूर्ण क्यों है? क्या आप हमेशा ठोस प्रकार को बुलाते हुए लिंक प्रश्न लिखते हैं, उदा।

from ItemChange itemChange in ItemChanges 

// instead of 

from itemChange in ItemChanges 

इसी प्रकार, क्या आप हमेशा प्रकार अनुमानों का उपयोग करने के बजाय जेनेरिक तरीकों के प्रकार के तर्कों को कॉल करते हैं, उदा।

ItemChanges.Select<ItemChange, ItemChange>((ItemChange itemChange) => ...); 

// instead of 

ItemChanges.Select(itemChange => ...); 

या आप संकलक बताने के लिए खुश हैं आप के लिए कुछ काम करना है और यह प्रकार, बाहर काम प्रकार की जानकारी नहीं होने की 'कीमत' पर जाने स्पष्ट रूप से कहा?

यदि आप linq और जेनेरिक तरीकों में प्रकार अनुमान के साथ खुश हैं, तो आप पहले से ही निर्णय ले चुके हैं कि आप ठीक से हर जगह स्पष्ट रूप से वर्तनी नहीं कर रहे हैं, और शायद आपको अपना कोड नहीं मिला है नतीजे के रूप में कम पढ़ने योग्य हो (वास्तव में, आप शायद काफी विपरीत पाया है)। तो var का उपयोग करना उसी पथ से बस एक और कदम है जिसे आप पहले से ही चालू कर रहे हैं।

Answer 7

वर एक सी # 3.0 सुविधा केवल गुमनाम प्रकार

में अनिवार्य है

var v = new { Amount = 108, Message = "Hello" }; 

गतिशील रूप से एक नई अज्ञात प्रकार बनाने के कोड निम्नलिखित कारण, वर उपयोग अनिवार्य है। उदाहरण के लिए, var विशेष रूप से लिंक में उपयोगी होता है जहां प्रकार अक्सर गतिशील रूप से बनाया जाता है।

किसी अन्य परिस्थिति में, यह केवल अंतिम आवेदन के लिए स्वाद का मामला है (इसे संकलन के दौरान हल किया गया है)। लेकिन कोड पाठकों के लिए, मुझे लगता है कि 'var' कम जानकारीपूर्ण है जो स्वयं टाइप करें।

Answer 8

किसी भी दिए गए राज्य में अज्ञात प्रकारों के अलावा var का उपयोग करने के लिए कोई तकनीकी कारण नहीं है।

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

public int SomeMethod(){} 
public List<T> SomeOtherMethod<T>(T parameter); 

को देखते हुए तो

var x = SomeMethod(); 
var y = SomeOtherMethod(x); 

काम करेगा (और y List<int> हो जाएगा)। आप

int x = SomeMethod(); 
List<int> y = SomeOtherMethod(x); 

का इस्तेमाल किया था तो अगर SomeMethod()long वापस जाने के लिए बदल रहे थे, तो आप y की परिभाषा को बदलने के लिए होगा।

मैंने इस तरह की चीज को पूरे कार्यक्रम में प्रचारित किया है, जिसमें सैकड़ों बदलाव की आवश्यकता है। List<T> की बजाय ReadOnlyCollection<T> वापस करने के लिए विशेष मामला डेटा एक्सेस कोड बदल रहा था। इतने सारे कोड परिवर्तन आवश्यक थे, मैंने List<T> के सभी स्पष्ट उल्लेखों को बदल दिया, और कोड को फिर से बदलने की आवश्यकता नहीं होगी।

Answer 9

हां, वे अलग हैं। var मूल डेटाटाइप और एक डेटाटाइप-चेक को हटा देता है, इसलिए यह अधिक खतरनाक है।

प्रकार-जांच

एक सामान्य चर परिभाषा प्रारंभिक काम पर एक डेटाप्रकार की जांच भी शामिल है।

T a = init;  // type-checked 
a = b;   // type-checked 
a = c;   // type-checked 

यह है जब आप var

var a = init; // NOT type-checked 
a = b;   // type-checked 
a = c;   // type-checked 

का उपयोग याद आ रही है ये संकलन समय परीक्षण गोंद जो बड़े कार्यक्रमों को एक साथ बांधता है। उन्हें हटाने मूर्ख है।

दुर्घटना में परिवर्तन

एक सामान्य चर परिभाषा एक तय प्रकार है - यह गलती से नहीं बदला जा सकता।

TOrig a = init(e);   // datatype fixed (as intended) 

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

var a = init(e);   // datatype changes with init and e 

समय के साथ, के रूप में सॉफ्टवेयर संपादित किया जाता है, डेटाप्रकार गलती से बदला जा सकता है।
यह पहले से ही हो सकता है, और आप नहीं बता सकते हैं।

उदाहरण:

public double MaxValue = 1.2; 

    ... meanwhile, in another source file ... 

    var x = MaxValue - 1; 
    var y = IsFull(x); 

दोनों x और y के डेटाटाइप्स गलती से संपादन MAXVALUE से बदल रहा जा सकता है।
प्रश्न: क्या यह पहले से ही हुआ है?

सारांश

var का उपयोग करते हुए एक अनियंत्रित चलती भाग में स्थानीय चर के डेटाप्रकार बदल जाता है।
मशीन के जितने अधिक चलने वाले हिस्सों में ब्रेक करना अधिक संभावना है।

स्पष्ट डेटाटाइप बग को रोकता है।