استخدام المتغيرات المحلية المكتوبة ضمنيًا [نسخة مكررة]

Question

هذا السؤال لديه بالفعل إجابة هنا:

• لماذا سيكون var أمرًا سيئًا؟ 17 إجابة

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

public string SomeMethod(int aParam)
{
    int aNumber = SomeOtherMethod(aParam);
    // should be changed to:
    var aNumber = SomeOtherMethod(aParam);
}

أعتقد أن المتغيرات المكتوبة بشكل صريح أكثر قابلية للقراءة (أكثر وضوحًا).

ما رأيك في اقتراح ReSharper؟هل هناك أي ميزة في استخدام المتغيرات المكتوبة ضمنيًا؟متى تستخدم vars الضمنية/الصريحة؟

Answer 1

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

var someVariable = new List<int>();

في المثال أعلاه، من الواضح أن "var" يشير إلى "List<int>".

لا أحب استخدام "var" عندما يتعين علي الانتقال إلى بعض تعريفات الطريقة لمعرفة نوع المتغير الذي يمثله "var" أو من خلال الاضطرار إلى الاعتماد على Visual studio intelli-popup أو أي شيء يسمى، على سبيل المثال هذا في ليس بخير بالنسبة لي:

var someVaraible = SomeMethod();

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

Answer 2

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

أنا شخصيا تفضل المتغيرات المكتوبة بشكل صريح، ولكن عند استخدام المجموعات العامة المتداخلة، يمكن أن تصبح الأشياء أكثر قابلية للقراءة باستخدام متغير مكتوب ضمنيًا.ينظر الى:

Dictionary<string, Dictionary<string, string>> myDictionary = new Dictionary<string, Dictionary<string, string>>();

ضد:

var myDictionary = new Dictionary<string, Dictionary<string, string>>();

يحرر:يغطي موضوع SO هذا نفس الموضوع، مع بعض الردود اللطيفة: ما يجب استخدامه:فار أو نوع اسم الكائن؟

تحرير 2:من خلال العمل كثيرًا مع غير المتزامن في الوقت الحاضر، وجدت أن استخدام المتغيرات المكتوبة بشكل واضح يمكن أن يمنع الأخطاء السيئة في بعض الأحيان.خذ بعين الاعتبار هذا المثال السخيف حيث قد ترغب في إرجاع معرف المستخدم.ضع في اعتبارك ذلك أيضًا GetUserAsync يعود أ Task<User>.إذا كنت تستخدم متغيرات مكتوبة ضمنيًا، فسينتهي بك الأمر باستخدام شيء مثل هذا:

public long GetUserId()
{
  var user = GetUserAsync();
  return user.Id;
}

هذا يجمع، ولكن من الخطأ."المستخدم" هو في الواقع أ Task<User>.ويجمع كما Task لديها أيضا Id ملكية.في هذه الحالة، قد يقوم أحد الأشخاص بإرجاع معرف المهمة عن طريق الخطأ بدلاً من المستخدم.

public long GetUserId()
{
  User user = GetUserAsync();
  return user.Id;
}

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

لقد حدث لي هذا بالفعل مرة واحدة :-)

Answer 3

فقط في حالة عدم ملاحظة البعض بعد، يمكنك بسهولة تغيير "الاقتراحات" في Reshaper (Reshaper -> الخيارات -> اللغات -> إجراءات السياق -> "استبدال مواصفات النوع الصريحة بـ 'var'").

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

Answer 4

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

Answer 5

FWIW، الكلمة الأساسية var قابلة للقراءة بوضوح في كثير من الحالات.خاصة إذا...

1. الجانب الأيمن من المهمة هو تعبير منشئ.

   خريطة فار = قاموس جديد>();

2. المتغيرات المحلية لها أسماء جيدة.

هث