لماذا يكون var شيء سيء؟

Question

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

هل يعرف أحد لماذا سيكون فكرة سيئة استخدام الكلمة الرئيسية في C #؟

Answer 1

كتاب إرشادات تصميم الإطار الإطار (كتاب رائع) الذي خرج في نوفمبر 2008 يوصي بالنظر في استخدام var عندما يكون النوع واضحا ولا لبس فيه.

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

في الكتاب (الملحق أ)، فإنها تعطي بالفعل هذا المثال:

var names = new List<string>(); // good usage of var

string source = GetSource();
var tokens = source.Split(' '); // ok; most developers know String.Split

var id = GetId(); // Probably not good; it's not clear what the type of id is

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

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

Answer 2

var q = GetQValue();

هو في الواقع شيء سيء. ومع ذلك،

var persistenceManager = ServiceLocator.Resolve<IPersistenceManager>();

جيد تماما بالنسبة لي.

القاع هو: استخدام أسماء المعرف الوصفي وستحصل على ما يرام.

ك Sidenote: أتساءل كيف يتعاملون مع أنواع مجهولة عند عدم السماح باستخدامها var الكلمة الرئيسية. أو أنها لا تستخدمها تماما؟

Answer 3

في معظم الحالات، عند الاستخدام المعقول (أي تهيئة نوع بسيط حيث النوع والقيمة هي نفسها)، فلا بأس بذلك.

هناك عدة مرات عندما يكون من غير الواضح أنك كسرت الأشياء عن طريق تغييرها - بشكل أساسي، عندما لا يكون نوع التهيئة والنوع المتغير (الأصلي) هو نفسه، لأنه:

• كان المتغير في الأصل الطبقة الأساسية
• كان المتغير في الأصل واجهة
• كان المتغير في الأصل نوعا آخر مع عامل تحويل ضمني

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

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

في مثل هذه الحالات، يمكنك تغيير معنى التعليمات البرمجية، وتنفيذ شيء مختلف. هذا هو ثم شيء سيء.

أمثلة:

التحويل الضمني:

static void Main() {
    long x = 17;
    Foo(x);
    var y = 17;
    Foo(y); // boom
}
static void Foo(long value)
{ Console.WriteLine(value); }
static void Foo(int value) {
throw new NotImplementedException(); }

طريقة الاختباء:

static void Main() {
    Foo x = new Bar();
    x.Go();
    var y = new Bar();
    y.Go(); // boom
}
class Foo {
    public void Go() { Console.WriteLine("Hi"); }
}
class Bar : Foo {
    public new void Go() { throw new NotImplementedException(); }
}

إلخ

Answer 4

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

لا معنى جميع معايير ترميز الشركات، عملت ذات مرة بالنسبة لشركة أرادت بادئة جميع أسماء الفئة مع اسم الشركة. كان هناك إعادة صياغة هائلة عندما غيرت الشركة اسمها.

Answer 5

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

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

Answer 6

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

1. لا يقلل من السلامة من النوع
2. سيزيد في الواقع السلامة من النوع في التعليمات البرمجية الخاصة بك من خلال تنبيهك إلى إيصالات ضمنية. أفضل مثال في بيان foreach
3. يحافظ على مبادئ جافة في C #. هذا هو خصيصا لحالة الإعلان، لماذا يزعج اسم القول الاسم مرتين؟
4. في بعض الحالات انها ثابتة مطلوبة. مثال أنواع مجهولة
5. أقل الكتابة دون فقدان الوظائف.

http://blogs.msdn.com/jaredpar/archive/2008/09/09/When-To-use-Type-inerence.aspx.

Answer 7

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

صديقك ليس فقط من المؤسف أنهم يعملون تحت أحد المتطرفين.

Answer 8

يحظر ذلك يعني تماما منع استخدام الأنواع المجهولة (التي تصبح مفيدة بشكل لا يصدق أثناء استخدام LinQ أكثر).

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

Answer 9

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

Answer 10

هذه هي مشكلة قابلية للقراءة حقا مع التعليمات البرمجية الخاصة بك.

تفضيلاتي الشخصية هي فقط استخدام "Var" فقط لأنواع مجهولة (بالفعل، إذا كنت ترغب في استخدام أنواع مجهولة الهوية على الإطلاق، فستحتاج إلى استخدام Var)، وتأتي معظمها من استفسارات LinQ. في هذه الحالات، ليس لديك أي خيار سوى استخدام VAR إذا كان استعلامك يتسهلا إلى نوع جديد (ضمني أو مجهول).

ومع ذلك، فإن C # 3.0 سيسمح لك بسعادة باستخدام Var في أي مكان تريده، خارج LinQ وأنواع مجهولة، على سبيل المثال:

var myint = 0;
var mystring = "";

هو صالح تماما، وسيتم كتابة القيم و myint و myString بقوة من خلال القيم المتنتورة المستخدمة لتهيئة لهم. (وهكذا، myint هو system.int32 و myString هو نظام. بالطبع، من الواضح إلى حد ما عند النظر إلى القيم المستخدمة لتهيئة المتغيرات التي سيتم كتابتها ضمنيا، ومع ذلك، أعتقد أنه أفضل لقراءة التعليمات البرمجية إذا كتبت أعلاه ك:

int myint = 0;
string mystring = "";

نظرا لأنك تستطيع أن ترى على الفور في لمحة ما نوع المتغيرات بالضبط.

النظر في هذا السيناريو المربك إلى حد ما:

var aaa = 0;
double bbb = 0;

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

Answer 11

قد تفكر في رأي Microsoft ذا صلة، لأن C # هي لغتهم:

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

يرى MSDN - المتغيرات المحلية المكتوبة ضمنيا (دليل البرمجة C #), ، الفقرة الأخيرة.

---

يجب أن تكون على علم بذلك فار يزيل اختبار النمط وقت الترجمة في المهمة الأولية.

var x = "mistake";     // error not found by compiler
int x = "mistake";     // error found

نظرا لأن معظم المتغيرات مخصصة فقط مرة واحدة، واستخدام متسق فار يزيل جميع اختبارات Datatype تقريبا على تعيينات متغيرة.

هذا يجعل رمزك عرضة للتغيرات العرضية مثل تلك التي تصنعها أدوات دمج أو المطورين المتعبين.

Answer 12

الكتابة الضمنية رائعة، والأشخاص الذين يحظرون أن يضروا إنتاجية الإنتاجية ودعوة رمز هش.

انها تقريبا مثل كتابة البط آمنة، ومترجم تم فحصها، وهو مفيد بشكل لا يصدق عند إعادة الإنفاق. على سبيل المثال، إذا كان لدي طريقة تقوم بإرجاع قائمة، وأعدت ذلك لإرجاع iEnaryerable، فسيكون أي متصلين على هذه الطريقة التي استخدمت الكلمة الرئيسية للاستخدام والأساليب iEnumerable فقط على ما يرام. إذا قمت بتحديد صراحة، على سبيل المثال، قائمة، ثم عليك أن أذهب وتغيير ذلك إلى ienumerable في كل مكان.

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

Answer 13

اريك ليبيرت يلخصه جيدا:

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

رأيي الخاص: أجد صعوبة في القراءة ولا معنى له بعض الشيء مع أنواع مثل int, string, bool أو حتى أ User. وبعد إنه حول قابلية القراءة بعد كل شيء (باستثناء المكان الذي تستخدمه مع LinQ)، لذلك عندما تكون الفارغية موضعية حول الأمر قد يكون من الصعب قراءة وهزيمة الغرض من الكلمات الرئيسية التي أقصدها مصممي اللغة.

Answer 14

من قسم التكرار في الإعلان (من جيف الترميز الرعب):

"يمكنني استخدام الكتابة المتغيرة الضمنية كلما وأينما في أي مكان يجعل الرمز الخاص بي أكثر إيجازا. يجب أن يزيل أي شيء يزيل التكرار من التعليمات البرمجية بقوة - ما يصل إلى ما يصل إلى لغات التبديل.

أنا نفسي أعتقد ذلك يكون يستحق الاستيلاء عليها، ولكن إنشاء مبادئ توجيهية شاملة عند استخدامها أو لا مبالغة.

Answer 15

لقد حازت حالات (عندما أكون من خلال طاولة. تحصيلها) عند استخدام VAR نتج عن النوع الذي يكون من بعض الفئة الأساسية بدلا من نوع Datarow الفعلي. هذه هي المرة الوحيدة التي كان لدي مشكلة مع var.

Answer 16

"فار" هو واضح أن تكون واضحة

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

تماما كما لو كنت تكتب قصة لا يوجد إجابة محددة نهائية. ولكن دعونا نلقي نظرة على بعض الأمثلة على ذلك في اللغة الإنجليزية العادية.

قال جيك مرحبا إلى بيل. لم يعجبه لذلك التفت وذهب في الاتجاه الآخر.

من ذهب في الاتجاه الآخر؟ جيك أو فاتورة؟ في هذه الحالة "جيك" و "فاتورة" هي مثل اسم النوع. و "هو" و "هو" مثل الكلمة الرئيسية var. في هذه الحالة قد يساعد ذلك في أن تكون أكثر تحديدا. ما يلي على سبيل المثال هو أكثر وضوحا.

قال جيك مرحبا إلى بيل. لم يعجب جيك فاتورة حتى تحول وذهب في الاتجاه الآخر.

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

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

في هذه الحالة، سيكون من الأسهل قراءة الجملة إذا استخدمنا "هو" وفي بعض الحالات ترك اسمه معا، فهذا هو ما يعادل استخدام var الكلمة الرئيسية.

فاتورة يحب الكتب، لذلك ذهب إلى المكتبة وأخرج كتابا يحبه دائما.

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

في حالة الرمز، لديك اثنين من الكلمات "، والنوع واسم المتغير.

Person p = GetPerson();

السؤال الآن يصبح هناك معلومات كافية هناك من أجلك بسهولة تحديد ما p يكون؟ هل ما زلت تعرف ما هو الناس في هذا السيناريو:

var p = GetPerson();

ماذا عن هذه:

var p = Get();

ماذا عن هذه:

var person = Get();

ما سر جديدة هذا:

var t = GetPerson();

ما سر جديدة هذا:

var u = Person.Get();

ما إذا كانت الكلمة الرئيسية var يعتمد Works في سيناريو معين على سياق التعليمات البرمجية، مثل ما هي أسماء المتغيرات والفئات والأساليب، وكذلك تعقيد التعليمات البرمجية.

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

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

Answer 17

فيما يلي نتائج اختبار ركضت على كفاءة var مقابل كتابة صريحة:

  private void btnVar_Click(object sender, EventArgs e)
    {
        Stopwatch obj = new Stopwatch();
        obj.Start();
        var test = "Test";
        test.GetType();
        obj.Stop();
        lblResults.Text = obj.Elapsed.ToString();
    }

    private void btnString_Click(object sender, EventArgs e)
    {
        Stopwatch obj = new Stopwatch();
        obj.Start();
        string test = "Test";
        obj.Stop();
        lblResults.Text = obj.Elapsed.ToString();

    }

النتيجة التسمية الأولى هي: 0000:00 000034

نتيجة التسمية الثانية هي: 0000:00 00008