تنسيق عبارات if

Question

هذه ليست حربًا مقدسة، وليست مسألة "أيهما أفضل".

ما هي إيجابيات استخدام التنسيق التالي للبيان الفردي إذا كانت الكتل.

if (x) print "x is true";

if(x) 
    print "x is true";

في مقابل

if (x) { print "x is true"; }
if(x) {
    print "x is true";    
}

إذا قمت بتنسيق بيانك الفردي بدون أقواس أو تعرف مبرمجًا يفعل ذلك، ما الذي دفعك/هم إلى تبني هذا الأسلوب في المقام الأول؟أنا مهتم على وجه التحديد بالفوائد التي جلبها لك هذا.

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

1. الاكتناز
2. أكثر قابلية للقراءة بالنسبة للبعض
3. تستدعي الأقواس النطاق، الذي له حمل نظري في بعض الحالات

Answer 1

أجد هذا:

if( true ) {
    DoSomething();
} else {
    DoSomethingElse();
}

أفضل من هذا:

if( true )
    DoSomething();
else
    DoSomethingElse();

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

Answer 2

أنا لا أحب بشدة أي أسلوب يضع اختبار if والنص على نفس الخط.

وذلك لأن مشاركة السطر تجعل من المستحيل تعيين نقطة توقف على نص if في العديد من مصححات الأخطاء لأن نقاط التوقف تعتمد عادةً على رقم السطر.

Answer 3

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

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

يبدأ الأمر، ببراءة كافية، ببيان if بسيط.

if (condition)
    do_something();
else
    do_something_else();

الذي هو كل شيء حسن وجيد.

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

if (condition)
    if (condition2)
        do_something();
else
    do_something_else();

هل ترى هذه المشكلة؟قد يبدو الأمر صحيحًا لكن المترجم يراه بشكل مختلف.ويرى الأمر هكذا:

if (condition)
    if (condition2)
        do_something();
    else
        do_something_else();

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

Answer 4

أنا دائما استخدم

if(x) 
{
    print "x is true";    
}

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

Answer 5

أنا أستعمل

if (x)
{
    DoSomething();
}

لأسطر متعددة، لكني أفضل الخطوط التي لا تحتوي على أقواس:

if (x)
   DoSomething();
else
   DoSomethingElse();

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

Answer 6

if
{
// code
}
else 
{
// else code
}

لأنني أحب عندما تصطف كتل التعليمات البرمجية (بما في ذلك الأقواس).

Answer 7

إذا قمت بالرمز:

if(x) 
    print "x is true";

وبعد 6 أشهر أحتاج إلى إضافة سطر جديد، فوجود الأقواس المتعرجة يجعل من غير المرجح أن أكتب

if(x) 
    print "x is true";
    print "x is still true";

مما قد يؤدي إلى خطأ منطقي، مقابل:

if(x) { 
    print "x is true";
    print "x is still true";
}

لذا أجد أن الأقواس المتعرجة تجعل مثل هذه الأخطاء المنطقية أسهل في القراءة وتجنبها.

Answer 8

مثل مات (3 أعلاه)، أفضل:

if (x)
{
    ...statement1
    ...statement2
}

و

if (x)
    ...statement
else
    ...statement

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

Answer 9

عبارة واحدة إذا كانت الكتل تفتقر إلى الأقواس:

الايجابيات:

• عدد أقل من الشخصيات
• نظرة أنظف

سلبيات:

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

كما في:

if(x) 
    print "x is true";
    print "something else";

Answer 10

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

public void MyFunction(object param)
{
     if (param == null) return;

     ...
}

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

Answer 11

أنا أستعمل

if (cond) {
  ...
} else {
  ...
}

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

Answer 12

جويل سبولسكي كتب مقالة جيدة: جعل التعليمات البرمجية الخاطئة تبدو خاطئة

ويتناول هذه القضية على وجه التحديد…

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

في هذه الحالة يكون الرمز صحيحًا بنسبة 100%؛إنه يتوافق مع معظم اتفاقيات الترميز ولا يوجد شيء خاطئ في ذلك ، ولكن حقيقة أن الجسم الواحد في الإطار غير محاط بأقواس قد يزعجك ، لأنك قد تفكر في مؤخرة رأسك ، يا إلهي ، شخص ما ، شخص ما قد أدخل سطر رمز آخر هناك

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

... وتنسى إضافة الأقواس ، وبالتالي جعل foo (i) غير مشروط!لذلك عندما ترى كتلًا من الكود غير الموجود في الأقواس ، فقد تشعر بمجموعة صغيرة من النجاسة التي تجعلك غير مرتاح.

يقترح عليك…

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

Answer 13

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

if (x)
   print "x is true"
for (int i=0; i<10; i++)
   print "y is true"

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

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

Answer 14

المساحة البيضاء هي صديقتك ....

ولكن مرة أخرى، أحب:

if (foo)
{
    Console.WriteLine("Foobar");
}

Answer 15

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

if (a)
  foo();
  bar();

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

*(التحذير عند foo();حاجِز()؛كان توسيعًا للماكرو، ولكن هذه مشكلة مع وحدات الماكرو، وليس الأقواس المتعرجة مع ifs.)

Answer 16

if (x) {
    print "x is true";    
}
else {
    do something else;
}

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

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

Answer 17

الطريقة الأخرى هي أن تكتب:

(a==b) ? printf("yup true") : printf("nop false");

سيكون هذا عمليًا إذا كنت تريد تخزين قيمة مقارنة بشرط بسيط، مثل:

int x = (a==b) ? printf("yup true") : printf("nop false");

Answer 18

if (x)
{
    print "x is true";
}

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

Answer 19

المرة الوحيدة التي يبدو فيها أن عدم الترابط مقبول هو عند التحقق من المتغيرات في بداية الطريقة:

public int IndexOf(string haystack, string needle)
{
    // check parameters.
    if (haystack == null)
        throw new ArgumentNullException("haystack");
    if (string.IsNullOrEmpty(needle))
        return -1;

    // rest of method here ...

الفائدة الوحيدة هي الاكتناز.لا يتعين على المبرمج الخوض في عناصر {} غير الضرورية عندما يكون من الواضح تمامًا أن:

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

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

Answer 20

اللعنة على H8ers فأنا لست حقًا من أصحاب القواعد العقائدية.في بعض المواقف، سأفضل في الواقع الاكتناز إذا لم يتم تشغيله على عرض معين، على سبيل المثال:

if(x > y)      { xIsGreaterThanY(); }
else if(y > x) { yIsGreaterThanX; }
else           { xEqualsY(); }

هذا أكثر قابلية للقراءة بالنسبة لي من:

if( x > y ){
    xIsGreaterThanY(); 
}else if( x < y){
    yIsGreaterThanX();
}else{
    xEqualsY();
}

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

Answer 21

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

Answer 22

وطالما كان ذلك متسقًا بين الفريق الذي تعمل فيه، فلا يهم كثيرًا

أن يفعل الجميع نفس الشيء هو الشيء الرئيسي

Answer 23

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

Answer 24

إذا كنت تفعل شيئا مثل هذا:

if(x)
{
    somecode;
}
else
{
    morecode;
}

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

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

Answer 25

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

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

Answer 26

/* I type one liners with brackets like this */
if(0){return(0);}
/* If else blocks like this */
if(0){
    return(0);
}else{
    return(-1);
}

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

Answer 27

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

if (x) {
    print "x is true";    
} else {
    do something else;
}

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

if (x) {
    print "x is true";    
}
//else {
//    do something else;
//}

Answer 28

أنا أفضّل هذا دائمًا:

if (x) doSomething();

if (x) {
    doSomthing();
    doOtherthing();
}

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

Answer 29

لا يهم، هذا هو الطريق الذي سأذهب إليه!يبدو الأفضل.

If(x)
{
    print "Hello World !!"
}
Else
{
    print "Good bye!!"
}

Answer 30

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