سؤال

هذا السؤال سبق الجواب هنا:

هذا هو السؤال الذي عند البرمجة أتساءل دائما:ماذا تستخدم عندما يتم كتابة التعليمات البرمجية:

var myFiles = Directory.GetFiles(fullPath);

أو

string[] myFiles = Directory.GetFiles(fullPath);

فار هو جديد و هو ضمنا كتبته المتغيرات المحلية, لذا نحن يمكن فقط استخدام محليا ولها قواعد مثل لا يمكن أن تكون فارغة ، وما إلى ذلك ، ولكن أتساءل عما إذا كان يمكننا الحصول على أي ميزة من استخدامه "عادة".

و "عادة" جزء يقول: ليس في مجهول أنواع, موضوع جمع المهيآت و تعبيرات الاستعلام حيث كان القصد من استخدام فار كائن مجهول, ما اعنيه هو...تماما مثل المثال أعلاه.

ما هي أفكارك ؟

هل كانت مفيدة؟

المحلول

أبعد من الاستخدام الواضح ل var مع LINQ، أستخدمه أيضًا لاختصار إعلانات المتغيرات الكثيرة لسهولة القراءة، على سبيل المثال:

var d = new Dictionary<string, Dictionary<string, Queue<SomeClass>>>();

بشكل عام، أشعر بنوع من الراحة (لعدم وجود كلمة أفضل) من الكتابة الثابتة مما يجعلني مترددًا في التخلي عنها.يعجبني الشعور بأنني أعرف ما أفعله عندما أعلن عن متغير.إن الإعلان عن متغير لا يعني فقط إخبار المترجم بشيء ما، بل إنه يخبر الشخص الذي يقرأ الكود الخاص بك بشيء ما.

اسمحوا لي أن أقدم لكم مثالا.لنفترض أن لدي طريقة ترجع ملف List<string>.هذا الرمز صحيح بالتأكيد، وأعتقد أن 90٪ من مطوري C# قد يكتبونه على الأرجح:

List<string> list = MyMethod();

من الواضح، أليس كذلك؟في الواقع، هذا هو المكان الذي يمكنك استخدامه بنفس السهولة var.

حقيقي بشكل كافي.لكن هذا إصدار الكود لا يعلن عن متغير فحسب، بل يخبرني بما ينوي الشخص الذي كتبه القيام به:

IEnumerable<string> list = MyMethod();

أخبرني المطور الذي كتب هذا الرمز "لن أقوم بتغيير هذه القائمة، ولن أستخدم فهرسًا للوصول إلى أعضائها.كل ما سأفعله هو التكرار عبرها." هذه معلومات كثيرة يمكن الحصول عليها في سطر واحد من التعليمات البرمجية.إنه شيء تتخلى عنه إذا استخدمته var.

بالطبع، لن تتخلى عنه إذا لم تستخدمه في المقام الأول.إذا كنت من النوع الذي قد يكتب هذا السطر من التعليمات البرمجية، فأنت تعلم بالفعل أنك لن تستخدمه var هناك.

يحرر:

لقد أعدت للتو قراءة مشاركة جون سكيت، وقد لفت انتباهي هذا الاقتباس من إريك ليبرت:

تعد الكلمات المحلية المكتوبة ضمنيًا مجرد طريقة صغيرة يمكنك من خلالها إعادة التأكيد على الكيفية وبالتالي التأكيد على ماذا.

أعتقد أن استخدام الكتابة الضمنية في كثير من الحالات يؤدي إلى ترك ما هو ضمني.لا بأس في عدم الخوض في ما.على سبيل المثال، سأكتب عرضًا استعلام LINQ مثل:

var rows = from DataRow r in parentRow.GetChildRows(myRelation)
           where r.Field<bool>("Flag")
           orderby r.Field<int>("SortKey")
           select r;

عندما أقرأ هذا الرمز، أحد الأشياء التي أفكر فيها عندما أقرأها هو "rows هو IEnumerable<DataRow>." لأنني أعلم أن ما ترجعه استعلامات LINQ هو IEnumerable<T>, ، ويمكنني رؤية نوع الكائن الذي تم تحديده هناك.

هذه هي الحالة التي يكون فيها ماذا لم يفعل ذلك تم توضيحها.لقد ترك لي أن أستنتج.

الآن، في حوالي 90% من الحالات التي أستخدم فيها LINQ، لا يهم هذا الأمر ولو قليلًا.لأنه في 90% من الحالات، يكون السطر التالي من التعليمات البرمجية هو:

foreach (DataRow r in rows)

ولكن ليس من الصعب تصور الكود الذي سيكون من المفيد جدًا الإعلان عنه rows مثل IEnumerable<DataRow> - الكود الذي يتم فيه الاستعلام عن العديد من أنواع الكائنات المختلفة، ولم يكن من الممكن وضع إعلان الاستعلام بجوار التكرار، وسيكون من المفيد أن تكون قادرًا على الفحص rows مع التحسس الذكي.وهذا هو الشيء، وليس كيف.

نصائح أخرى

سوف تحصل على مجموعة كبيرة من الآراء حول هذا واحد من "استخدام فار في كل مكان" إلى "استخدام فقط مع فار مجهول أنواع ، حيث الأساس." أحب إريك ليبرت على ذلك:

كل رمز هو التجريد.ما رمز "حقا" فعل هو التلاعب في البيانات ؟ لا.الأرقام ؟ بت ؟ لا.الفولتية?لا.الإلكترونات?نعم ، ولكن فهم رمز على مستوى الإلكترونات هي فكرة سيئة!فن الترميز هو معرفة ما حق مستوى التجريد هو الجمهور.

في لغة عالية المستوى هناك دائما هذا التوتر بين ما الرمز (لغويا) و كيف رمز يحقق ذلك.صيانة المبرمجين تحتاج إلى فهم كل ماذا إذا أنهم ذاهبون أن تكون ناجحة في إجراء التغييرات.

المغزى من LINQ هو أنه على نطاق واسع على "كيف" ، على نطاق واسع تؤكد على "ما".قبل باستخدام استعلام الفهم ، مبرمج يقول المستقبل جمهور "أعتقد أنه يجب أن لا أعرف ولا يهمني بالضبط كيف هذا نتيجة تعيين يتم احتساب لكنك ينبغي أن تهتم كثيرا حول ما دلالات الناتجة المجموعة." أنها تجعل رمز أقرب إلى سير الأعمال التي يجري تنفيذها ، أبعد من بت الإلكترونات التي تجعل من الذهاب.

ضمنا كتبته المحليين واحد فقط صغيرة الطريقة التي يمكنك deemphasize كيف ومن ثم التأكيد على ما.إذا كان هذا هو الشيء الصحيح أن تفعل في حالة معينة هو حكم الدعوة.لذلك أنا أقول للناس أن إذا كانت المعرفة من النوع ذات الصلة وخيارها هو أمر حاسم في واستمرت العملية من طريقة ، ثم لا تستخدم الضمني الكتابة.الكتابة صريحة تقول "أنا أقول لك كيف يعمل هذا لسبب الدفع الاهتمام".ضمني الكتابة ويقول "إنه لا يهم ما إذا كان هذا الشيء قائمة أو العملاء[], ما يهم هو أنه مجموعة من العملاء".

شخصيا لا تميل استخدامه إذا كان نوع ليس من المعقول واضحة - حيث تتضمن استعلامات LINQ بأنها "معقولة واضحة".أنا لا أفعل ذلك من أجل Directory.GetFiles على سبيل المثال, كما أنه ليس من الواضح أن إرجاع string[] بدلا من (مثلا) ، FileInfo[] (أو شيء آخر تماما) - و أن يجعل فرقا كبيرا في ما يمكنك القيام به في وقت لاحق.

إذا كان هناك منشئ الاتصال على الجانب الأيمن من عامل التعيين ، أنا أكثر بكثير من المرجح أن تذهب مع var:الأمر واضح بشكل صارخ ما سيتم.هذا هو مفيد خاصة مع مجمع أنواع عامة ، على سبيل المثال Dictionary<string,List<int>>.

أنا شخصياً أستخدم var فقط في مكانين:

  1. مع أنواع مجهولة، أي.المتعلقة بـ LINQ (حيث يكون var مطلوبًا في بعض الحالات)
  2. عندما يعلن البيان ويبني نوع معين في نفس النوع

أي.وهذا مثال للنقطة 2:

var names = new List<String>();

تم تحريره:هذا ردًا على سؤال جون سكيت.

تم تبسيط الإجابة أعلاه في الواقع.في الأساس، أنا استخدم فار حيث يكون النوع إما:

  1. ليس من الضروري أن نعرف (ليس هناك الكثير من الأماكن رغم ذلك)
  2. من المستحيل معرفة (LINQ، الأنواع المجهولة)
  3. وإلا فهو معروف، أو واضح من الكود

في حالة طريقة المصنع، حيث كل ما تحتاج إلى معرفته في المكان الذي تكتب فيه الكود هو أن الكائن الذي تحصل عليه هو سليل من نوع ما، وذلك بعض الانواع لديه طريقة مصنع ثابتة، ثم سأستخدمها فار.مثله:

var connection = DatabaseConnection.CreateFromConnectionString("...");

المثال أعلاه هو مثال حقيقي من الكود الخاص بي.من الواضح، على الأقل بالنسبة لي وللأشخاص الذين يستخدمون هذا الرمز، أن اتصال هو سليل DatabaseConnection، لكن النوع الدقيق ليس ضروريًا لفهم الكود أو استخدامه.

لقد جربت أسلوب "استخدام var في كل مكان" ...ولهذا السبب لم أستمر في استخدامه.

  1. تدهور إمكانية القراءة في بعض الأحيان
  2. حدود التحسس بعد =
  3. لم تكن كتابة "var" أقصر بكثير من كتابة "int" و"string" وما إلى ذلك، خاصة مع التحسس.

ومع ذلك، ما زلت أستخدمه مع LINQ.

أنا قادم من أرض البرمجة الوظيفية، حيث يحكم استنتاج النوع اليوم var لجميع السكان المحليين حيثما أمكن ذلك.

في Visual Studio، إذا كنت تتساءل يومًا عن نوع أي محلي، فكل ما عليك فعله هو التمرير فوقه باستخدام الماوس.

هذا بريد احصل على بعض الإرشادات الجيدة حول وقت استخدام واجهة النوع var أو أنواع الكائنات.

أنا أميل إلى استخدام var في كل مكان، لكن زملائي في العمل قالوا توقف، فهو أقل قابلية للقراءة بالنسبة لنا.لذلك أنا الآن أستخدم var فقط على الأنواع المجهولة واستعلامات LINQ وأين يوجد المُنشئ على الجانب الأيمن.

أعتقد أنه من المثير للاهتمام ملاحظة كيفية التعامل مع هذا الأمر عادةً في هاسكل.شكرا ل تماثل الكاري هوارد, ، يمكن استنتاج النوع (الأكثر عمومية) لأي تعبير في هاسكل، وبالتالي لا تكون إعلانات النوع مطلوبة في أي مكان، مع بعض الاستثناءات؛على سبيل المثال، في بعض الأحيان تريد عمدًا قصر النوع على شيء أكثر تحديدًا مما يمكن استنتاجه.

وبطبيعة الحال فإن المطلوب والمستحب ليسا شيئاً واحداً؛من الناحية العملية، يبدو أن التقليد هو أن التعريفات ذات المستوى الأعلى تحتوي دائمًا على إعلانات النوع، في حين أن التعريفات المحلية تحتوي على إعلانات النوع مهملة.يبدو أن هذا يحقق توازنًا جيدًا بين الوضوح من أجل سهولة القراءة للتعريف ككل، على النقيض من الإيجاز من أجل سهولة القراءة للتعريفات "المساعدة" أو "المؤقتة" المحلية.إذا فهمت بشكل صحيح، لا يمكنك استخدامها var للتعريفات "المستوى الأعلى" (مثل الطريقة أو الوظيفة العامة) في المقام الأول، لذلك أعتقد أن هذا يترجم إلى "استخدام var في كل مكان يمكنك" في عالم C#.طبعا اكتب "int" هو نفس عدد ضغطات المفاتيح مثل "var"، ولكن معظم الأمثلة ستكون أطول من ذلك.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top