الترتيب الصحيح للمنطق هيكل الرقابة (صح / خطأ، كاذبة / صحيح)؟

Question

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

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

وسيكون من الصعب على التكيف مع هذا الرأي 'سلبي'، أنا يفضلون نظرة أكثر إيجابية، على افتراض كل شيء هو الصحيح:)

Answer 1

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

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

    if(arg == null){ 
      throw new IllegalArgumentException();  // harsh (correct)
    }
    // or 
    if(arg == null){
        arg = "";  // forgiving (lazy)
    }

وبعد ذلك، وأنا أحاول أن تحقق ل1 حالة فقط في كل-بيان إذا. بدلا من

    if(condition1 && condition2) {
        ...
    } else {
        ...
    }

وانا افضل عموما

    if(condition1) {
        if(condition2) {
            ...
        } else {
            ...
        }
    } else {
        ...
    }

وهذا النهج هو أسهل لتحديد نقاط التوقف، ويجعل المنطق أكثر obvous.

وأنا تجنب الإنكار. بدلا من

    if(! condition) {
        ...a...
    } else {
        ...b...
    }

والأمور أفضل ترتيبها ل

    if(condition) {
        ...b...
    } else {
        ...a...
    }

وأخيرا، يجب أن يكون كل الأساليب التي إرجاع نتيجة منطقية اسم "الإيجابي" الذي يشير إلى ما تعنيه النتائج:

    boolean checkSomething(Something x){ ... }     // bad -- whats the result?
    boolean isSomethingInvalid(Something x){ ... } // better, but ...
    boolean isSomethingValid(Something x){ ... }   // best, no "mental negation"

Answer 2

وهناك نقاشا ممتازا من مجرد هذا الموضوع في كود ماكونيل أكمل . انها الكتاب الذي أوصى. على أي حال مناقشة ذات الصلة هي في الصفحات 706-708 من الطبعة الأولى أو ص. 749-750 من الطبعة الثانية (بفضل التفاف على لوحات). من هذا الكتاب:

<اقتباس فقرة>   

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

Answer 3

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

if( condition is true ) {
    do something small;
} else { 
    do something;
    and something else; 
    . . .
    and the 20th something;
}

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

if( variable is defined ) {
    if( variable == value ) {
        ...
    }
}

وبدلا من ذلك:

if( (variable is defined) && (variable == value) ) {
     ...
}

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

Answer 4

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

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

Answer 5

وانظر أيضا هذا السؤال:

<وأ href = "https://stackoverflow.com/questions/166550/what-to-put-in-the-if-block-and-what-to-put-in-the-else-block" > ما وضعه في كتلة IF وما يتم تنفيذه في كتلة ELSE؟

Answer 6

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

مثال - اختبار لمعرفة ما اذا فترة من 2 مواعيد يتقاطع مع فترة أخرى من 2 مواعيد وأسهل في الكتابة كما الاختبار لا تقاطع من 2 فترات

Answer 7

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

Answer 8

وإما / أو. أنا عموما استخدام النهج "السلبي" على الرغم من.

وإذا (! شيئا) {

و}

Answer 9

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

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

Answer 10

و(السياق: جاوة)

وREADABILITY1: الشرط الذي يحل إلى كتلة أصغر من التعليمات البرمجية يذهب أولا

if (condition) {
  smallBlock();
} else {
  bigBlockStart();
  ........
  bigBlockEnd();
}

وREADABILITY2: تأكيد إيجابي يذهب أولا، لأنه من السهل عدم ملاحظة علامة النفي

وجعل الشعور: تأكيد جميع الشروط المسبقة لطريقة استخدام Assert.blabla () واستخدام الشرطية فقط من أجل ما يفعله طريقة

.