الاستخدام الإلزامي للأقواس

Question

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

مثال:

// this is wrong
if (foo) 
    //bar
else 
    //baz
while (stuff)
    //things

// This is right.
if (foo) {
    // bar
} else {
    // baz
}
while (things) {
    // stuff
}

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

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

Answer 1

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

لذلك، هذا صحيح من قبل المعايير الخاصة بي:

if(true) continue;

كما هو هذا

if(true) return;

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

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

Answer 2

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

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

Answer 3

أرى هذه القاعدة كما overkill. لا تجعل المعايير الدائرية مبرمونة جيدة، فهي تقلل من احتمالات أن تصنع Slob فوضى.

الأمثلة التي تقدمها صالحة، لكن لديهم حلول أفضل من إجبار الأقواس:

عندما لا تستعد بخط واحد، ثم يقوم شخص ما بتعليقاته، فأنت في ورطة.

اثنين من الممارسات حل هذا أفضل، اختيار واحد:

1) تعليق خارج if, while, ، وما إلى ذلك قبل بطانة واحدة مع بطانة واحدة. أي علاج

if(foo)
    bar();

مثل أي بيان آخر متعدد الخطوط (مثل تعيين مع خطوط متعددة، أو مكالمة وظيفة متعددة الخط):

//if(foo)
//    bar();

2) بادئة // مع ;:

if(foo)
;//    bar();

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

لا أنت لست؛ الرمز يعمل نفسه ولكن من الصعب القراءة. إصلاح المسافة البادئة الخاصة بك. اختيار علامات التبويب أو المساحات والعصا معهم. لا تخلط علامات التبويب والمساحات للمسافة البادئة. سيقوم العديد من محرري النص بإصلاح هذا تلقائيا لك.

اكتب بعض كود بيثون. هذا سوف يصلح على الأقل بعض عادات المسافة البادئة السيئة.

أيضا، هياكل مثل } else { تبدو وكأنها نسخة Nethack من مقاتلة التعادل لي.

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

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

int x = 0;
while(x < 10);
{
    printf("Count: %d\n", ++x);
}

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

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

Answer 4

لم يكن لدي أي شخص يأتي مع سبب وجيه لعدم استخدام الأقواس المجعد دائما.

الفوائد التي تتجاوز بكثير أي سبب سمعت.

توجد معيار ترميز لإجراء رمز أسهل لقراءة الأخطاء وتقليلها.

هذا هو معيار واحد يدفع حقا.

Answer 5

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

Answer 6

أقف على الأرض أن الأقواس يجب أن تتطابق وفقا للمسافة البادئة.

// This is right.
if (foo) 
{
    // bar
}
else 
{
    // baz
}

while (things) 
{
    // stuff
}

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

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

Answer 7

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

Answer 8

حكمي الشخصية هو إذا كان الأمر قصير جدا "إذا"، ثم ضع كل شيء على سطر واحد:

if(!something) doSomethingElse();

بشكل عام، استخدم هذا فقط عندما يكون هناك مجموعة من IFS مثل هذا على خلافة.

if(something == a) doSomething(a);
if(something == b) doSomething(b);
if(something == b) doSomething(c);

هذا الموقف لا ينشأ في كثير من الأحيان، وإلا، وإلا، فأنا دائما استخدام الأقواس.

Answer 9

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

أعترض على نفس السبب أعترض على الفرق التي تحظر استخدام استثناءات أو قوالب أو وحدات ماكرو: إذا اخترت استخدام لغة، فاستخدم اللغة بأكملها. إذا كانت الأقواس اختيارية في C و C ++ و JAVA، فإن تكليفها باتفاقية تظهر بعض الخوف من اللغة نفسها.

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

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

Answer 10

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

تحقيق التوازن بين المنفعة ضد التكلفة (كل قاعدة إضافية يربك ويرتبرب المبرمجين، وبعد عتبة معينة، يقلل في الواقع من فرصة أن يتبع المبرمون أي من القواعد)

لذلك، لجعل المعيار الترميز:

• تأكد من أنه يمكنك تبرير كل قاعدة مع أدلة واضحة على أنه أفضل من البدائل.

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

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

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

• حريق أي مبرمج يعلق على أجزاء عشوائية من التعليمات البرمجية دون قراءة ذلك :-)

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

Answer 11

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

if (foo)     
//bar
else     
//baz

يمكن كتابتها كثغر باستخدام مشغل Ternary:

foo ? bar : baz

و

while (something is true)
{
blah 
}

يمكن كتابتها على النحو التالي:

blah while(something is true)

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

Answer 12

أنا لا أقول أنه من غير المعقول، ولكن في 15 عاما من الترميز مع اللغات التي تحبها C، لم أتمكن من حدوث مشكلة واحدة في حذف الأقواس. وتعليقا على فرع يبدو وكأنه مشكلة حقيقية من الناحية النظرية - لم أر ذلك يحدث في الممارسة العملية.

Answer 13

ميزة أخرى دائما باستخدام الأقواس هي أنه يجعل عمليات البحث والاستبدال والعمليات الآلية المماثلة أسهل.

على سبيل المثال: لنفترض أنني لاحظ ذلك functionB عادة ما يطلق عليه مباشرة بعد functionA, مع نمط مماثل من الحجج، لذلك أريد إعادة إدماج الكود المكرر في جديد combined_function. وبعد يمكن أن تتعامل Regex بسهولة التعامل مع هذا إعادة المربع إذا لم يكن لديك أداة قوية بما فيه الكفاية (^\s+functionA.*?;\n\s+functionB.*?;) ولكن، بدون الأقواس، قد يفشل نهج Regex بسيط:

if (x)
  functionA(x);
else
  functionA(y);
functionB();

قد يصبح

if (x)
  functionA(x);
else
  combined_function(y);

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

Answer 14

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

Answer 15

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

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

• إذا أدى العبارة الشرطية نفسها الإجراءات اللازمة، فستكون النموذج:

  for (init; term; totalCount++)
  {
      // Intentionally left blank
  }
  

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

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

Answer 16

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

ومع ذلك، أنا أحب العائدات الواحدة المستمرة التي يقترحها GUS. النية واضحة، وهي أنظف وأسهل القراءة.

Answer 17

إذا كان لديك الوقت الكافي للقراءة من خلال كل هذا، فاحرض الوقت لإضافة الأقواس الإضافية.

Answer 18

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

لا أستطيع أن أقدم مضادا أفضل أيضا. آسف! ؛)

Answer 19

بالنسبة للأشياء مثل هذا، أود أن أوصي بمجرد الخروج مع قالب التكوين ل ATSOFormatter IDE الخاص بك. ثم، كلما ضرب المستخدمون Alt-shift-f (أو مهما كان ضغط المفاتيح في IDE الخاص بك الاختيار)، سيتم إضافة الأقواس تلقائيا. ثم فقط قل للجميع: "المضي قدما وتغيير تلوين الخط، وإعدادات PMD أو أيا كان. يرجى عدم تغيير قواعد المسافة البادئة أو القواعد التلقائية، على الرغم من".

يستفيد ذلك من الأدوات المتاحة لنا لتجنب الجدال حول شيء ما لا يستحق الأكسجين الذي يقضيه عادة.

Answer 20

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

C ++:

النسخة 1:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 ) throw InvalidOperation();
   return a/b;
}

الإصدار 2:

class InvalidOperation{};

//...
Divide(10, 0);
//...
Divide(int a, in b)
{
   if(b == 0 )
   { 
      throw InvalidOperation();
   }
   return a/b;
}

C #:

النسخة 1:

foreach(string s in myList)
   Console.WriteLine(s);

الإصدار 2:

foreach(string s in myList)
{
   Console.WriteLine(s);
}

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

Answer 21

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

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

الجماليات والقراءة لا علاقة لها بذلك.