لماذا لا تصنع العبارات التي لا تفعل أي شيء استثناء (أو تحذر المطور)؟

Question

لقد تعرضت للعض عدة مرات بالبيانات في VB.NET (لست متأكدًا مما إذا كان هذا التأثير موجودًا في C#) يبدو أنه مرجع ذاتي ، لكن عندما يتم تنفيذه ، فإنهم لا يفعلون أي شيء بالفعل لأنهم يحتاجون الهدف ولا يتم توفير واحد. علي سبيل المثال:

Dim MyString as string = "String to test"

' Neither of these lines do anything '
MyString.Replace(" ", "-")
MyString.Substring(0,5)

' This will return the original string, because neither statement did anything '
Messagebox.Show(MyString)

في كلتا الحالتين ، لا يبدو أنه يزعج .NET أن البيان يحتاج إلى هدف لتعيين النتيجة ، وأنا لا أعطيها واحدة. هل هناك سبب لعدم تحذيرني IDE/برنامج التحويل البرمجي من هذا التأثير ، أو أنه لم يتم إلقاء استثناء "itsdoesntdoanything"؟ نظرًا لأن الكود يتكون بطريقة لن يغير أي شيء أبدًا ، فمن الواضح أنه سوء التصرف.

Answer 1

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

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

Answer 2

نعم ، سيكون من الرائع أن تتميز الأساليب التي لا تحتوي على آثار جانبية بنوع من [NoSideEffectSattribute ()] بحيث يمكن لأدوات مثل المجمعين أن تحذرك ، ولكن في الوقت الحالي ، لا يوجد شيء من هذا القبيل معروف لي.

ولكن يمكنك تجربة FXCOP ، يمكن أن يكتشف الكثير من أخطاء البرمجة الدقيقة على مجموعات .NET.

Answer 3

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

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

Answer 4

غالبًا ما يكون من الصعب على المترجم تحديد ما إذا كانت الوظائف "تفعل شيئًا". ما لم يكن المترجم صارما التحليل المشترك (IPA) ، لا يمكن تحديد ما إذا كان لمكالمة الوظيفة لها تأثير جانبي.

IPA هي عملية بطيئة تزيد بشكل كبير من متطلبات ذاكرة المترجمين ، لذا فإن معظم المجمعين لا يقومون بذلك بشكل افتراضي.

Answer 5

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

variableName = functionName([parameterlist]);  

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

functionName([parameterlist]);  

إذا لم تفعل.

بالنسبة لأساليب الوظيفة التي ليس لها آثار جانبية (مثل تلك التي ذكرتها) كما لاحظت ، فإن هذا لا معنى ...

Answer 6

لست متأكدًا

1) افترض أنك تضيف كلمة رئيسية عندما تكون قيمة الإرجاع البصرية (وبالتالي يعني أنها عادة ما تكون إلزامية) من شأن

2) لنفترض أنك تقوم بالعكس ، وإضافة كلمة رئيسية عند إجبار قيمة الإرجاع ، فإن بعض الأشخاص سيستخدمون ببساطة متغيرات وهمية لتخزينها ومواصلة استخدامها بالطريقة التي تستخدم بها.

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

Answer 7

النظر في الطريقة Dictionary<TKey, TValue>.TryGetValue(TKey key, out TValue value): يتحقق مما إذا كان المفتاح موجودًا في القاموس ، وإذا كان كذلك ، فإنه يضع القيمة في out معامل. قيمة الإرجاع أ bool مشيرا ما إذا كانت العملية ناجحة. في بعض الأحيان تهتم. في بعض الأحيان لا تفعل ذلك. أعتقد أن هذا نهج مقبول للغاية لطرق مثل هذه ؛ إذا أجبرك المترجم على تعيين قيمة الإرجاع إلى متغير ، فسيكون لدى الأشخاص الكثير من التعليمات البرمجية مثل هذا:

int someValue = 0;
bool discard = IntDictionary.TryGetValue("key", out someValue);

// I don't even care if discard is true or false;
// someValue will be 0 if it wasn't in IntDictionary

Answer 8

لقد تعرضت للعض عدة مرات

القفز إلى الاستنتاجات ، وليس عن طريق

عبارات في vb.net ... هذا ... لا تفعل أي شيء في الواقع

ولكن هذا في الواقع موثقة بشكل جيد للغاية.