الاستمرار يعتبر ضار؟[مغلق]

https://stackoverflow.com/questions/57600

09-06-2019
|

سؤال

هل يجب على المطورين تجنب استخدام يكمل في C# أو ما يعادله في اللغات الأخرى لفرض التكرار التالي للحلقة؟هل تتداخل الحجج المؤيدة أو المعارضة مع الحجج المتعلقة بـ اذهب إلى?

المحلول

أعتقد أنه يجب أن يكون هناك المزيد من الاستخدام للمتابعة!

في كثير من الأحيان أجد رمزًا مثل:

for (...)
{
   if (!cond1)
   {
      if (!cond2)
      {
          ... highly indented lines ...
      }
   }
}

بدلاً من

for (...)
{
   if (cond1 || cond2)
   {
      continue;
   }

   ...
}

استخدمه لجعل الكود أكثر قابلية للقراءة!

نصائح أخرى

يكون continue أي ضرر أكثر من، على سبيل المثال، break?

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

يمكنك كتابة تعليمات برمجية جيدة مع أو بدون متابعة، ويمكنك كتابة تعليمات برمجية سيئة مع أو بدون متابعة.

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

لا توجد كلمات رئيسية ضارة.هناك فقط استخدامات ضارة لهم.

Goto ليس ضارًا في حد ذاته، ولا الاستمرار.إنهم بحاجة إلى استخدامها بعناية، هذا كل شيء.

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

أحب استخدام الاستمرار في بداية الحلقات للتعامل مع شروط if البسيطة.

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

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

أريد أن أقول:"هذا يعتمد".

إذا كان لديك رمز حلقة صغير إلى حد معقول (حيث يمكنك رؤية رمز الحلقة بالكامل دون التمرير) فمن الجيد عادةً استخدام المتابعة.

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

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

لا أعتقد أن الاستمرار يمكن أن يكون صعبًا مثل goto نظرًا لأن الاستمرار لا ينقل التنفيذ أبدًا خارج كتلة التعليمات البرمجية الموجودة فيه.

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

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

يمكن استخدام goto كمتابعة، ولكن ليس العكس.

يمكنك "الانتقال" إلى أي مكان، وبالتالي كسر التحكم في التدفق بشكل تعسفي.

وهكذا تستمر، ليست ضارة تقريبا.

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

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

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

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

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

بالنسبه لهذا المبرمج متداخلة إذا/آخر تعتبر ضارة.

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

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

الاستمرار يشعر بالخطأ بالنسبة لي.الاستراحة تخرجك من هناك، ولكن يبدو أن الاستمرار مجرد معكرونة.

من ناحية أخرى، يمكنك محاكاة الاستمرار مع الفاصل (على الأقل في Java).

for (String str : strs) contLp: {
    ...
       continue contLp;
    ...
}

الاستمرار يمكن أن يكون مفيدًا في بعض الظروف، لكنه لا يزال يبدو قذرًا بالنسبة لي.

for (char c : cs) {
    final int i;
    if ('0' <= c && c <= '9') {
        i = c - '0';
    } else if ('a' <= c && c <= 'z') {
        i = c - 'a' + 10;
    } else {
        continue;
    }
    ... use i ...
}

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

أدخل أدوات التحليل الثابت.قد تصعب عليك الأمور..

وgoto، يبدو هذا بمثابة كابوس لنفس الأسباب ولكن في أي مكان عشوائي في الكود.

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow