ما هو النمط المفضل لبيانات القرار والإجراء الفردي؟

Question

في حالة اللغات التي تدعم القرار والإجراء المفرد بدون قوسين، مثل المثال التالي:

if (var == true)
    doSomething();

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

if (var == 1)
    doSomething(1);
else if (var > 1 && var < 10)
    doSomething(2);
else
{
    validate(var);
    doSomething(var);
}

Answer 1

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

if ( a == b)    {
    doSomething();
}
else {
    doSomething();
}

لكن هذه حرب مقدسة.

Answer 2

أوصي

if(a==b)
{
    doSomething();
}

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

if(a==b)
    doSomething();
    doSomethingElse();

يختلف كثيرا عن

if(a==b)
{
    doSomething();
    doSomethingElse();
}

يرى مقال جويل لمزيد من التفاصيل

Answer 3

أنا أميل إلى استخدام الأقواس في جميع الأوقات.يمكنك الحصول على بعض الأخطاء الدقيقة حيث بدأت بشيء مثل:

if(something)
 DoOneThing();
else
  DoItDifferently();

ثم قرر إضافة عملية أخرى إلى else جملة وننسى أن نلفها بين قوسين:

if(something)
 DoOneThing();
else
  DoItDifferently();
  AlwaysGetsCalled(); 

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

Answer 4

أفضّل أن تكون متسقًا، على سبيل المثال، إذا كنت تستخدم الأقواس في كتلة واحدة، فاستخدم الأقواس في كل مكان حتى مع عبارة واحدة فقط:

if (cond1)
{
   SomeOperation();
   Another();
}
elseif (cond2)
{
   DoSomething();
}
else
{
   DoNothing();
   DoAnother();
}

ولكن إذا كان لديك مجموعة واحدة فقط من الخطوط:

if (cond1)
    DoFirst();
elseif (cond2)
    DoSecond();
else
    DoElse();

يبدو أنظف (إذا كنت لا تمانع في استخدام أسماء الطرق الوهمية؛) بهذه الطريقة، ولكن هذا أنا فقط.

ينطبق هذا أيضًا على بنيات الحلقة وما شابه:

foreach (var s as Something)
    if (s == someCondition)
        yield return SomeMethod(s);

يجب عليك أيضًا أن تضع في اعتبارك أن هذا هو التقليد الذي قد يكون أكثر ملاءمة لـ .NET (لاحظ أن Java peepz ترغب في الحصول على أول قوس متعرج لها في نفس السطر مثل if).

Answer 5

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

وقبل أن يصل الحكماء إلى الأمر، لا، لم يكن السبب هو أن "الجميع يستخدم تقويم الأسنان دائمًا".

لذا، سؤال صادق - أود حقًا الحصول على ردود فعلية بدلاً من مجرد التصويت السلبي:هل يحدث هذا في الواقع؟

(يحرر:لقد سمعت ما يكفي من قصص الرعب عن الاستعانة بمصادر خارجية لتوضيح بعض الشيء:هل يحدث ذلك في الواقع؟ المبرمجين المختصين?)

Answer 6

لا يهم حقًا، طالما أنك متسق معه.

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

Answer 7

وأود أن أدافع بقوة دائماً باستخدام الأقواس، حتى عندما تكون اختيارية.لماذا؟خذ هذه القطعة من كود C++:

if (var == 1)
  doSomething();
doSomethingElse();

الآن، يأتي شخص لا يولي اهتمامًا كافيًا ويقرر أن هناك شيئًا إضافيًا يجب أن يحدث إذا (var == 1)، لذلك يفعل هذا:

if (var == 1)
  doSomething();
  doSomethingExtra();
doSomethingElse();

لا يزال كل شيء به مسافة بادئة بشكل جميل ولكنه لن يفعل ما كان مقصودًا.

من خلال استخدام التقويم دائمًا، من المرجح أن تتجنب هذا النوع من الأخطاء.

Answer 8

أنا شخصياً أؤيد شرح ماكونيل من Code Complete.

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

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

ابدأ بكتابة أشياء مثل:

If A == true
   FunctA();

If B == "Test"
{
   FunctB();
}

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

ابحث بشكل أساسي عن ما تشعر بالراحة في كتابته في كل مرة والتزم به.أنا أؤمن باستخدام محددات الكتلة('{', '}') قدر الإمكان هو الطريق الصحيح.

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

If A == false {
  //calls and whatnot
}
//or
If B == "BlaBla"
{
  //calls and whatnot
}
//or
If C == B
  {
  //calls and whatnot
  }

من فضلك لا تجيب على هذا لأنه سيكون سؤال جديد.إذا رأيت اهتماما بهذا سأفتح سؤالا جديدا مدخلاتك.

Answer 9

لقد استخدمت دائمًا الأقواس في جميع الأوقات باستثناء الحالة التي أقوم فيها بالتحقق من متغير NULL قبل تحريره، كما هو ضروري في C

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

if (aString) free(aString);

Answer 10

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

Answer 11

روبي يتجنب بشكل جيد قضية واحدة في المناقشة.المعيار للبطانة الواحدة هو:

do_something if (a == b)

ولمتعدد الخطوط:

if (a == b)
  do_something
  do_something_else
end

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

هذا غير متوفر (حتى الآن) في Java، ولا في العديد من اللغات الأخرى، AFAIK.

Answer 12

كما ذكر آخرون، فإن تنفيذ عبارة if في سطرين بدون أقواس يمكن أن يؤدي إلى حدوث ارتباك:

if (a == b)
    DoSomething();
    DoSomethingElse(); <-- outside if statement

لذلك أضعه في سطر واحد إذا كان بإمكاني القيام بذلك دون الإضرار بسهولة القراءة:

if (a == b) DoSomething();

وفي جميع الأوقات الأخرى أستخدم الأقواس.

المشغلون الثلاثيون مختلفون قليلاً.في أغلب الأحيان أفعلها في سطر واحد:

var c = (a == b) ? DoSomething() : DoSomethingElse();

ولكن في بعض الأحيان ، تحتوي البيانات على مكالمات وظائف متداخلة ، أو تعبيرات Lambda التي تجعل من الصعب تحليل بيان خط واحد بصريًا ، لذلك أفضل مثل هذا:

var c = (a == b)
    ? AReallyReallyLongFunctionName()
    : AnotherReallyReallyLongFunctionOrStatement();

لا يزال أكثر إيجازًا من كتلة if/else ولكن من السهل رؤية ما يحدث.

Answer 13

الشمس اتفاقيات التعليمات البرمجية للغة برمجة جافا لديه هذا ليقول:

يجب أن تحتوي فئة العبارات IF-ELSE على النموذج التالي:

if (condition) {
    statements;
}

if (condition) {
    statements;
} else {
    statements;
}

if (condition) {
    statements;
} else if (condition) {
    statements;
} else {
    statements;
}

Answer 14

رئيسنا يجعلنا نضع { } بعد بيان القرار مهما كان، حتى لو كان عبارة واحدة.إنه أمر مزعج حقًا إضافة سطرين إضافيين.الاستثناء الوحيد هو عوامل التشغيل الثلاثية.

أعتقد أنه من الجيد أن يكون لدي جهاز مراقبة الكود الخاص بي في الاتجاه الرأسي بدقة 1200 × 1600.

Answer 15

أنا أفضل

if (cond)
   {
   //statement
   }

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

نعم، أحب وضع مسافة بادئة بين قوسين على مستوى الكتلة أيضًا.

بايثون لطيفة لأن المسافة البادئة تحدد الكتلة.السؤال مطروح في لغة كهذه.

Answer 16

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

if (i != 0)
bar(i);
foo(i);

Foo الآن غير مشروط.وهو أمر سيء حقا!

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

Answer 17

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

Answer 18

في لغة Perl، إذا كنت تجري اختبارًا بسيطًا، فسوف تكتبه في وقت ما بهذا النموذج:

do_something if condition;

do_something unless condition;

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

sub test{
  my($self,@args) = @_;

  return undef unless defined $self;

  # rest of code goes here

}

Answer 19

القاعدة الذهبية هي أنه عند العمل في مشروع حالي، اتبع معايير الترميز هذه.

عندما أكون في المنزل، لدي شكلين.

الأول هو السطر الواحد:

if (condition) doThis();

والثاني لعدة أسطر:

if (condition) {
   doThis();
}

Answer 20

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

if(!ok)return;

بالنسبة لأي سيناريو متعدد العبارات، على الرغم من أنني ما زلت أرى أن الأقواس يجب أن تكون إلزامية:

if(!ok){

    do();

    that();

    thing();
}