إطار رمز قوي؟

Question

أنا أكره كتابة التعليمات البرمجية التي تجعل برامجي أكثر صلابة. هذا شيء يجب أن يفعله الإطار! لذلك ، هل يدرك أي شخص أداة "تعزيز" الأداة المساعدة التي تصلب الرمز؟

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

تشوه الرمز بمحاولة ، وضع تصحيحًا.

قم بتسجيل إدخال كل طريقة ، وطباعة قيم "ToString ()" للوسائط ، حتى أتمكن من تتبع ما يحدث.

تحقق من كل حجة لـ NULL.

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

اذا لما لا؟

Answer 1

إذا كنت ترغب في تسجيل المكالمات ، يمكنك استخدام إطار عمل AOP مثل postsharp. من الأفضل تحقيق أشياء مثل تطبيق الأسلوب المسبق/ما بعد ذلك باستخدام آليات التصميم على حدة مثل الجديد عقود رمز المكتبة التي ستشحن مع .NET4.0. من المؤكد أنه من غير المنطقي التحقق من وسيطات NULL لأن هذا قد يكون قيمة صالحة حسب الطريقة. حقن debug.Asserts في التعليمات البرمجية قد يكون مشكلة حيث قد لا ترغب في/أن تكون قادرًا على التعامل مع الاستثناءات في وظيفة المصدر. أعتقد أنه سيكون من غير العملي إن لم يكن من المستحيل إنشاء إطار عام لهذا النوع من الأشياء لأن المتطلبات ستختلف اختلافًا كبيرًا بين المشاريع.

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

public void SomeMethod(args)
{
    try
    {
        //original method body
    }
    catch(Exception ex)
    {
        Debug.Assert(false);
        throw;
    }
}

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

public void SomeMethod(object arg)
{
    Debug.Assert(arg != null);
    if(arg == null) throw new ArgumentNullException("arg");

    //rest of method
}

هذه ممارسة مفيدة ، وأعتقد أن مكتبة Code Contrans تدعم التحقق المسبق "إرث" (استثناءات الرمي) في تحليلها الثابت.

Answer 2

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

Answer 3

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

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

Answer 4

أشك في وجود شيء من هذا القبيل ، وإذا كان الأمر كذلك ، فهذا ليس من الممكن استخدامه. يعتمد ذلك على تعريفات القواعد الخاصة بك ، ويعتقد أشخاص مختلفين مختلفًا ، ولديهم احتياجات وأطر مختلفة ... يمكن تحقيق الأشياء التي وصفتها عن طريق metaprogramming أو نظام ماكرو. في Java ، هناك بعض المشاريع التي يمكن أن تساعد في تنفيذ مثل هذا النهج التعليقات التوضيحية ، لا تعرف ما إذا كان هناك بعض المكافئ في C# Universe. ومع ذلك ، فإن وظيفة ISValid () تشبه إلى حد كبير التصميم حسب فكرة العقد ، وربما هناك بعض الأطر لذلك.