هل يجب أن أقمع CA1062: التحقق من صحة حجج الأساليب العامة؟

Question

لقد قمت مؤخرًا بترقية مشروعي إلى Visual Studio 2010 من Visual Studio 2008.

في Visual Studio 2008 ، لا توجد قاعدة تحليل الكود هذه.

الآن لست متأكدًا مما إذا كان ينبغي علي استخدام هذه القاعدة أم لا.

أقوم ببناء مكتبة مفتوحة المصدر ، لذا يبدو من المهم منع الناس من ارتكاب الأخطاء. ومع ذلك ، إذا كان كل ما سأفعله هو رمي ArgumentNullException عندما تكون المعلمة null, ، يبدو وكأنه كتابة رمز عديمة الفائدة منذ ذلك الحين ArgumentNullException سيتم إلقاؤه حتى لو لم أكتب هذا الرمز.

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

هل يجب علي إزالة هذه القاعدة أو إصلاح الانتهاكات؟

Answer 1

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

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

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

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

Answer 2

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

Answer 3

رقم IMHO رقم Nulls لن يكون أبدًا عنق الزجاجة في التطبيق. (وفي حالة واحدة من المليون من القضية حيث تكون مهمة ، ستجدها مع profiler الخاص بك وإزالة تلك الحالة الواحدة).

السؤال الآخر الذي يجب أن يتشكل في ذهنك هو "هل رمي NullReferenceException () حقًا أفضل طريقة للتعامل مع الخطأ؟" غالبًا ما يمكنك التعامل مع الأشياء بشكل أفضل من ذلك (حتى لو كان فقط لتقديم تقرير خطأ أفضل للمستخدم و/أو نفسك لأغراض تصحيح الأخطاء). في كثير من الحالات ، يمكن أن تتعامل الكود مع Nulls بأمان ، مما يجعل من غير الضروري أن يكون هذا خطأً على الإطلاق.

تعديل

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

لا يوجد موقف يكون فيه التعطل أو الفشل أمرًا جيدًا. من الأفضل دائمًا "إبطاء التطبيق الخاص بك" مع الشيكات الفارغة من التعطل وفقدان بيانات عميلك.

لذلك لا تحسن قبل الأوان رمزك. اكتبها جيدًا ، لتكون قابلة للصيانة وقوة ، إذن الملف الشخصي لمعرفة أين توجد اختناقات. لقد تم برمجة لمدة 28 عامًا ، وأكون ليبرالية للغاية مع الشيكات الفارغة ، ولدي أبداً وجدت أن الفحص الفارغ كان سبب مشكلة الأداء. عادةً ما تكون أشياء مثل القيام بالكثير من العمل غير الضروري في حلقة ، باستخدام خوارزمية O (n^3) حيث يكون نهج O (n^2) ممكنًا ، وفشل في تخزين ذاكرة التخزين المؤقت للقيم باهظة الثمن ، إلخ.