معيار ترميز Java/أفضل الممارسات - اصطلاح التسمية لملصقات التوقف/المتابعة

Question

في بعض الأحيان، يمكن للفاصل أو المتابعة المسمى أن يجعل التعليمات البرمجية أكثر قابلية للقراءة.

OUTERLOOP: for ( ;/*stuff*/; ) {
    //...lots of code

    if ( isEnough() ) break OUTERLOOP;
    //...more code
}

كنت أتساءل ما هو الاصطلاح المشترك للملصقات.جميع القبعات؟القبعة الأولى؟

Answer 1

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

Answer 2

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

outer_loop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outer_loop;
    //  more code
  }
  //  more code
}

نعم، مثل هذه الحالات تحدث دائمًا.ما الذي يقترحه الأشخاص لاستخدامه بدلاً من ذلك؟شرط منطقي مثل هذا؟

for (...) {
  //  some code
  boolean continueOuterLoop = false;
  for (...) {
    //  some code
    if (...) {
      continueOuterLoop = true;
      break;
    }
    //  more code
  }
  if (continueOuterLoop)
    continue;
  //  more code
}

مقرف! إعادة هيكلتها كطريقة لا تخفف من ذلك أيضًا:

boolean innerLoop (...) {
  for (...) {
    //  some code
    if (...) {
      return true;
    }
    //  more code
  }
  return false;
}

for (...) {
  //  some code
  if (innerLoop(...))
    continue;
  //  more code
}

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

فلماذا أنتم جميعا ضد التسميات؟أعطني بعض الأسباب القوية والبدائل العملية للحالة المذكورة أعلاه.

Answer 3

الاتفاقية هي تجنب التسميات تماما.

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

for ( ;/*stuff*/; ) 
{
    lotsOfCode();

    if ( !isEnough() )
    {
        moreCode();
    }
}

---

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

Answer 4

يبدو أن نمط كود Java الخاص بشركة Sun يفضل تسمية التسميات بنفس طريقة تسمية المتغيرات، مما يعني حالة الجمل مع الحرف الأول بأحرف صغيرة.

Answer 5

التقليد الذي رأيته أكثر من غيره هو ببساطة حالة الجمل، مثل اسم الطريقة ...

myLabel:

لكنني رأيت أيضًا تسميات مسبوقة بشرطة سفلية

_myLabel:

أو مع المختبر...

labSomething:

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

Answer 6

wrt مثال كود سادي:

أنت أعطيت

outerloop:
for (...) {
  //  some code
  for (...) {
    //  some code
    if (...)
      continue outerloop;
    //  more code
  }
  //  more code
}

كمثال.لقد قمت بنقطة جيدة.أفضل تخميني سيكون:

public void lookMumNoLabels() {
  for (...) {
    // some code
    doMoreInnerCodeLogic(...);
  }
}

private void doMoreInnerCodeLogic(...) {
   for (...) {
      // some code
      if (...) return;
   }
}

ولكن قد تكون هناك أمثلة حيث لا يتوافق هذا النوع من إعادة الهيكلة بشكل صحيح مع أي منطق تقوم به.

Answer 7

نظرًا لأن التسميات نادرًا ما تكون مفيدة، يبدو أنه لا يوجد اتفاقية واضحة.تحتوي مواصفات لغة Java على مثال واحد يحتوي على تسميات وهي مكتوبة بدون_cap.

ولكن نظرًا لأنها نادرة جدًا، فمن الأفضل في رأيي التفكير مرتين فيما إذا كانت هي الأداة الصحيحة حقًا.

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

Answer 8

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

Answer 9

إنها نوع من goto لـ Java - لست متأكدًا مما إذا كانت C# تحتوي عليها.لم أستخدمها أبدًا عمليًا، ولا أستطيع التفكير في حالة لن يؤدي فيها تجنبها إلى كود برمجي أكثر قابلية للقراءة.

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

Answer 10

أعلم أنه لا ينبغي لي استخدام الملصقات.

لكن افترض فقط أن لدي بعض التعليمات البرمجية التي يمكن أن تكتسب الكثير من سهولة القراءة من الفواصل المسماة، كيف يمكنني تنسيقها.

مو، فرضيتك خاطئة.لا ينبغي أن يكون السؤال "كيف يمكنني تنسيقها؟"

يجب أن يكون سؤالك هو "لدي كود يحتوي على قدر كبير من المنطق داخل الحلقات - كيف أجعله أكثر قابلية للقراءة؟"

الإجابة على هذا السؤال هي نقل الكود إلى وظائف فردية ذات أسماء جيدة.إذن لا تحتاج إلى تسمية الفواصل على الإطلاق.