เหตุใดจึงถือว่าการปฏิบัติที่ไม่ดีในการละเว้นการจัดฟันแบบหยิก [ปิด]

ทำไมทุกคนบอกให้ฉันเขียนโค้ดแบบนี้เป็นการปฏิบัติที่ไม่ดี?

if (foo)
    Bar();

//or

for(int i = 0 i < count; i++)
    Bar(i);

อาร์กิวเมนต์ที่ใหญ่ที่สุดของฉันสำหรับการละเว้นวงเล็บปีกกาคือบางครั้งมันอาจเป็นสองเท่าของบรรทัดกับพวกเขา ตัวอย่างเช่นต่อไปนี้เป็นโค้ดบางส่วนที่ใช้ระบายสีเอฟเฟกต์แสงสำหรับฉลากใน C #

using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
{
    for (int x = 0; x <= GlowAmount; x++)
    {
        for (int y = 0; y <= GlowAmount; y++)
        {
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));
        }
     }
 }
 //versus
using (Brush br = new SolidBrush(Color.FromArgb(15, GlowColor)))
    for (int x = 0; x <= GlowAmount; x++)
        for (int y = 0; y <= GlowAmount; y++)
            g.DrawString(Text, this.Font, br, new Point(IconOffset + x, y));

คุณสามารถรับประโยชน์เพิ่มเติมจากการผูกมัดusingsกันโดยไม่ต้องเยื้องหนึ่งล้านครั้ง

using (Graphics g = Graphics.FromImage(bmp))
{
    using (Brush brush = new SolidBrush(backgroundColor))
    {
        using (Pen pen = new Pen(Color.FromArgb(penColor)))
        {
            //do lots of work
        }
    }
 }
//versus
using (Graphics g = Graphics.FromImage(bmp))
using (Brush brush = new SolidBrush(backgroundColor))
using (Pen pen = new Pen(Color.FromArgb(penColor)))
{
    //do lots of work
}

อาร์กิวเมนต์ที่พบบ่อยที่สุดสำหรับการจัดฟันแบบหยิกจะหมุนรอบการเขียนโปรแกรมบำรุงรักษาและปัญหาที่จะเกิดขึ้นโดยการแทรกรหัสระหว่างต้นฉบับถ้าคำสั่งและผลลัพธ์ที่ตั้งใจไว้:

if (foo)
    Bar();
    Biz();

คำถาม:

1. ผิดหรือไม่หากต้องการใช้ไวยากรณ์ขนาดกะทัดรัดที่ภาษาเสนอให้ คนที่ออกแบบภาษาเหล่านี้ฉลาดฉันไม่สามารถจินตนาการได้ว่าพวกเขาจะใส่คุณสมบัติที่ไม่ดีให้ใช้เสมอ
2. เราหรือเราไม่ควรเขียนโค้ดเพื่อให้ส่วนร่วมที่ต่ำที่สุดสามารถเข้าใจและไม่มีปัญหาในการทำงาน
3. มีอีกเหตุผลที่ฉันขาดหายไปหรือไม่?

ที่จริงแล้วครั้งเดียวที่ฉันกัดฉันจริงๆคือตอนที่ฉันกำลังดีบั๊กและแสดงความคิดเห็นในแถบ ():

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

นอกจากนั้นฉันมักจะใช้:

if(foo) bar();

ซึ่งดูแลกรณีข้างต้น

แก้ไขขอบคุณสำหรับการชี้แจงคำถามฉันเห็นด้วยเราไม่ควรเขียนรหัสไปยังตัวส่วนร่วมที่ต่ำที่สุด

ความเร็วในการอ่าน ...

นอกเหนือจากสิ่งที่ได้กล่าวไปแล้ว ณ จุดนี้ฉันได้รับเงื่อนไขในการแยกวิเคราะห์ว่างบที่มีเครื่องหมายวงเล็บและพื้นที่สีขาว ดังนั้นฉันอ่าน:

if (condition)
{
    DoSomething();
}

DoSomethingElse();

เร็วกว่าที่ฉันอ่านเล็กน้อย:

if (condition) DoSomething();

DoSomethingElse();

ฉันอ่านมันช้าลงเล็กน้อยถ้ามันเป็นเช่นนี้:

if (condition) DoSomething();
DoSomethingElse();

ฉันอ่านสิ่งนี้ช้ากว่าที่ผ่านมา:

if (condition) 
    DoSomething();
DoSomethingElse();

เพราะฉันไม่สามารถช่วย แต่อ่านมันอีกครั้งในกรณีและสงสัยว่าผู้เขียนตั้งใจ:

if (condition)
{
    DoSomething();
    DoSomethingElse();
}

โดยทั่วไปแล้วครอบคลุม แต่เมื่อมันมาถึงการอ่านด้านล่างฉันจะดูในขณะนี้เพื่อให้แน่ใจว่าสิ่งที่ผู้เขียนตั้งใจ ฉันอาจตามล่าผู้แต่งดั้งเดิมเพื่อยืนยัน

if (condition) 
    DoSomething();
    DoSomethingElse();

ถ้ามันมีขนาดเล็กเขียนแบบนี้:

if(foo()) bar();

หากมันยาวพอที่จะเจาะเป็นสองบรรทัดให้ใช้เครื่องหมายปีกกา

ฉันเคยคิดด้วยว่าควรใช้เหล็กดัดฟันเมื่อจำเป็นจริงๆเท่านั้น แต่ไม่ใช่อีกต่อไปเหตุผลหลักเมื่อคุณมีรหัสจำนวนมากมันจะทำให้อ่านง่ายขึ้นและคุณสามารถวิเคราะห์รหัสได้เร็วขึ้นเมื่อคุณมีสไตล์การค้ำยันที่สอดคล้องกัน

อีกเหตุผลที่ดีสำหรับการใช้เครื่องมือจัดฟันนอกเหนือจากคนที่เพิ่มคำสั่งที่สองใน if คือสิ่งที่อาจเกิดขึ้น

if(a)
   if(b)
     c();
else
   d();

คุณสังเกตว่าประโยคอื่นเป็นจริงของ "if (b)" หรือไม่? คุณอาจทำ แต่คุณจะเชื่อใจใครก็ตามที่คุ้นเคยกับ gotcha นี้หรือไม่?

ดังนั้นหากเพียงเพื่อความมั่นคงและเพราะคุณไม่เคยรู้ว่าสิ่งที่ไม่คาดคิดอาจเกิดขึ้นเมื่อมีคนอื่น (มันมักจะเป็นคนอื่นที่โง่) เปลี่ยนรหัสฉันมักจะใส่วงเล็บเพราะมันทำให้ซอร์สโค้ดอ่านง่ายขึ้น สมองของคุณ. สำหรับประโยคที่ง่ายที่สุดถ้าอย่างเช่นถ้ามีการมอบหมายหรือทำสลับเหมือนที่คุณรู้ว่าประโยคจะไม่ถูกขยายออกไปฉันจะปล่อยวงเล็บปีกกาออก

นี่ไม่ถือว่าเป็นการปฏิบัติที่ไม่ดีเสมอไป โครงการโมโน Coding แนวทางแนะนำที่จะไม่ใช้เครื่องหมายปีกกาถ้ามันไม่จำเป็น เหมือนกันสำหรับGNU มาตรฐานการเข้ารหัส ฉันคิดว่ามันเป็นเรื่องของรสนิยมส่วนตัวเช่นเคยกับมาตรฐานการเข้ารหัส

เส้นมีราคาถูก โปรเซสเซอร์พลังงานราคาถูก เวลานักพัฒนามีราคาแพงมาก

ตามกฎทั่วไปหากฉันไม่ได้พัฒนาแอพพลิเคชั่นที่สำคัญเกี่ยวกับทรัพยากร / ความเร็วฉันจะทำผิดด้านการเขียนโค้ดที่

(a) ง่ายสำหรับผู้พัฒนารายอื่นที่จะติดตามสิ่งที่ฉันทำ

(b) แสดงความคิดเห็นเฉพาะส่วนของรหัสที่อาจจำเป็นต้องใช้

(c) ง่ายต่อการแก้ไขข้อบกพร่องหากมีสิ่งผิดปกติ

(d) แก้ไขได้ง่ายหากจำเป็นต้องมีในอนาคต (เช่นการเพิ่ม / ลบรหัส)

ความเร็วหรือความสง่างามทางวิชาการของรหัสเป็นรองปัจจัยเหล่านี้จากมุมมองทางธุรกิจ นี่ไม่ได้เป็นการบอกว่าฉันตั้งใจจะเขียนโค้ด clunky หรือน่าเกลียด แต่นี่เป็นลำดับความสำคัญของฉัน

โดยการละเว้นวงเล็บปีกกาในกรณีส่วนใหญ่มันทำให้ฉัน (b), (c) และ (d) ยากขึ้น (หมายเหตุไม่เป็นไปไม่ได้) ฉันจะบอกว่าใช้วงเล็บปีกกาหรือไม่มีผลต่อ (a)

ฉันชอบความคมชัดที่วงเล็บปีกกาเสนอ คุณรู้แน่ชัดว่ามีความหมายอะไรและไม่ต้องเดาว่ามีใครบางคนเพิ่งทำผิดและทิ้งมันไว้ (และแนะนำบั๊ก) ครั้งเดียวที่ฉันละเว้นพวกเขาคือเมื่อฉันใส่ if และ action บนบรรทัดเดียวกัน ฉันไม่ได้ทำแบบนั้นบ่อยนัก จริง ๆ แล้วฉันชอบช่องว่างที่แนะนำโดยใส่วงเล็บปีกกาไว้บนบรรทัดของตัวเองแม้ว่าจากการเขียนโปรแกรมแบบ K&R เช่นเดียวกับปีที่ผ่านมาการสิ้นสุดบรรทัดด้วยวงเล็บปีกกาเป็นวิธีปฏิบัติที่ฉันต้องทำงานเพื่อเอาชนะถ้า IDE ไม่บังคับใช้ ผม.

if (condition) action();  // ok by me

if (condition) // normal/standard for me
{
   action();
}

ฉันคิดว่ามันเป็นเรื่องของแนวทางสำหรับโครงการที่คุณกำลังทำงานและรสนิยมส่วนตัว

ฉันมักจะละเว้นพวกเขาเมื่อพวกเขาไม่ต้องการยกเว้นบางกรณีเช่นต่อไปนี้:

if (something)
    just one statement; // i find this ugly
else
{
    // many
    // lines
    // of code
}

ฉันชอบ

if (something)
{
    just one statement; // looks better:)
}
else
{
    // many
    // lines
    // of code
}

หนึ่งในอินสแตนซ์ที่สิ่งนี้สามารถกัดคุณกลับมาในวันเก่าของมาโคร C / C ++ ฉันรู้ว่านี่เป็นคำถาม C # แต่บ่อยครั้งที่มาตรฐานการเข้ารหัสดำเนินการโดยไม่มีเหตุผลว่าทำไมมาตรฐานจึงถูกสร้างขึ้นตั้งแต่แรก

หากคุณไม่ได้ระวังตัวมากเมื่อสร้างมาโครคุณสามารถทำให้เกิดปัญหาได้หากข้อความที่ไม่ได้ใช้ {}

#define BADLY_MADE_MACRO(x) function1(x); function2(x);

if (myCondition) BADLY_MADE_MACRO(myValue)

ตอนนี้อย่าเข้าใจฉันผิดฉันไม่ได้บอกว่าคุณควรทำ {} เพื่อหลีกเลี่ยงปัญหานี้ใน C / C ++ เสมอ แต่ฉันต้องจัดการกับข้อผิดพลาดบางอย่างที่แปลกมากเพราะสิ่งนี้

ฉันเคยคิดแบบเดียวกัน

จนกระทั่งวันหนึ่ง (ทำไมมี "วันหนึ่ง" ที่เปลี่ยนชีวิตของคุณตลอดไป?) เราใช้เวลาตั้งแต่ 24 - 36 ชั่วโมงโดยไม่ต้องทำการดีบั๊กการสร้างรหัสเฉพาะการค้นหาว่ามีใครบางคนไม่ใส่วงเล็บรวมกับการเปลี่ยนแปลงการค้นหา / แทนที่ .

มันเป็นอะไรแบบนี้

 if( debugEnabled ) 
      println( "About to save 1 day of work to some very important place.");
 saveDayData();

สิ่งที่เกิดขึ้นหลังจากนั้น

 if( debugEnabled ) 
 //     println( "About to save 1 day of work to some very important place.");
 saveDayData();

ปรากฎว่าระบบสร้างบันทึก 500 mb ทุกวันและเราถูกขอให้หยุด แฟล็กการดีบักไม่เพียงพอดังนั้นการค้นหาและแทนที่ println นั้นเป็นไปตามลำดับ

ถึงกระนั้นเมื่อแอปไปผลิตการตั้งค่าสถานะการแก้ปัญหาถูกปิดและที่สำคัญ "saveDayData" ไม่เคยถูกเรียก

แก้ไข

ตอนนี้ที่เดียวที่ฉันไม่ใช้วงเล็บปีกกาอยู่ในถ้า / ลองสร้าง

if( object != null ) try { 
     object.close();
} catch( .....

หลังจากดูนักพัฒนาที่เก่งแล้วก็ทำเช่นนั้น

จะทื่อฉันเห็นมันเป็น:

โปรแกรมโปรแกรมเมอร์ที่ดีป้องกันได้โปรแกรมเมอร์ที่ไม่ดีทำไม่ได้

เนื่องจากมีหลายตัวอย่างข้างต้นและประสบการณ์ที่คล้ายกันของฉันกับข้อบกพร่องที่เกี่ยวข้องกับการลืมวงเล็บปีกกาจากนั้นฉันได้เรียนรู้วิธีที่ยากในการใส่สร้อยข้อมือเสมอ

สิ่งอื่นใดที่เลือกสไตล์ส่วนบุคคลมากกว่าเรื่องความปลอดภัยและนั่นคือการเขียนโปรแกรมที่ไม่ดีอย่างชัดเจน

โจเอลยังกล่าวถึงเรื่องนี้ในการสร้างรหัสผิดให้ดูผิด

เมื่อคุณได้รับข้อผิดพลาดเล็กน้อยเนื่องจากการจัดฟันที่ขาดหายไปคุณจะได้เรียนรู้ว่าการจัดฟันที่หายไปนั้นดูผิดเพราะคุณรู้ว่ามันเป็นสถานที่ที่มีโอกาสเกิดข้อผิดพลาดอื่นได้

ฉันมีความสุขมากที่:

foreach (Foo f in foos)
  foreach (Bar b in bars)
    if (f.Equals(b))
      return true;

return false;

โดยส่วนตัวฉันไม่เห็นสาเหตุ

foreach (Foo f in foos)
{
  foreach (Bar b in bars)
  {
    if (f.Equals(b))
    {
      return true;
    }
  }
}

return false;

สามารถอ่านได้มากขึ้น

ใช่เส้นนั้นฟรี แต่ทำไมฉันต้องเลื่อนหน้าและหน้าของรหัสเมื่อมันอาจมีขนาดครึ่งหนึ่ง?

หากมีความแตกต่างในการอ่านหรือการบำรุงรักษาให้แน่ใจว่าใส่วงเล็บใน ... แต่ในกรณีนี้ฉันไม่เห็นเหตุผลใด ๆ

นอกจากนี้ฉันจะใส่เครื่องหมายวงเล็บสำหรับซ้อนกันเสมอถ้าเป็นตำแหน่งที่ฉันซ้อนกันอยู่

if (condition1)
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();

VS

if (condition1)
  if (condition2)
    doSomething();
else (condition2)
  doSomethingElse();

สับสนอย่างมากดังนั้นฉันมักจะเขียนเป็น:

if (condition1)
{
  if (condition2)
    doSomething();
  else (condition2)
    doSomethingElse();
}

เมื่อใดก็ตามที่เป็นไปได้ผมใช้ประกอบ ternary แต่ฉันไม่เคย รังพวกเขา

ฉันยอมรับว่า "ถ้าคุณฉลาดพอที่จะให้คนอื่นจ่ายเงินให้คุณเพื่อเขียนโค้ดคุณควรฉลาดพอที่จะไม่พึ่งพาการเยื้องเพื่อดูการไหลของรหัสเพียงอย่างเดียว"

อย่างไรก็ตาม ... ข้อผิดพลาดสามารถทำได้และอันนี้เป็นความเจ็บปวดในการแก้ปัญหา ... โดยเฉพาะถ้าคุณมาดูรหัสของคนอื่น

ปรัชญาของฉันคือถ้ามันทำให้โค้ดอ่านง่ายขึ้นทำไมไม่ทำ?

เห็นได้ชัดว่าคุณต้องวาดเส้นบางแห่งเช่นการค้นหาสื่อที่มีความสุขระหว่างชื่อที่กระชับและมีความหมายมากเกินไป แต่วงเล็บจะหลีกเลี่ยงข้อผิดพลาดและปรับปรุงความสามารถในการอ่านของรหัส

คุณสามารถยืนยันว่าคนฉลาดพอที่จะเป็นนักเขียนโค้ดจะฉลาดพอที่จะหลีกเลี่ยงข้อบกพร่องที่เกิดจากคำสั่ง bracketless แต่คุณสามารถพูดได้ไหมว่าคุณไม่เคยสะดุดบางสิ่งที่ง่ายเหมือนการสะกดผิด Minutia เช่นนี้สามารถครอบงำเมื่อมองไปที่โครงการขนาดใหญ่

มีข้อยกเว้นอยู่เสมอ แต่ฉันจะโต้แย้งว่าไม่ใส่วงเล็บปีกกาเฉพาะเมื่ออยู่ในรูปแบบใดรูปแบบหนึ่ง:

if(x == y)
   for(/* loop */)
   {
      //200 lines
   }

//rampion's example:
for(/* loop */)
{
   for(/* loop */)
      for(/* loop */)
      {
         //several lines
      }
}

มิฉะนั้นฉันไม่มีปัญหากับมัน

บางครั้งฉันใช้รหัสด้านล่างมาก (หลายรายการโดยใช้คำสั่ง) แต่นอกเหนือจากนั้นฉันใส่วงเล็บไว้เสมอฉันเพิ่งพบว่ามันทำให้โค้ดชัดเจนขึ้น มันเห็นได้ชัดอย่างชัดเจนจากมากกว่าการเยื้องที่คำสั่งเป็นส่วนหนึ่งของบล็อก (และอาจเป็นส่วนหนึ่งของ if ฯลฯ )

ฉันได้เห็น

if (...)
    foo();
    bar();

ข้อผิดพลาดกัดฉัน (หรือมากกว่า "ฉันและเพื่อนร่วมงาน" - ฉันไม่ได้แนะนำข้อผิดพลาด) ครั้งเดียวครั้งเดียวนี่คือความจริงที่ว่ามาตรฐานการเข้ารหัสของเราในเวลาที่แนะนำให้ใช้วงเล็บปีกกาทุกที่ ฉันใช้เวลานานพอสมควรในการสังเกตเห็น - เพราะคุณเห็นสิ่งที่คุณต้องการเห็น (นี่คือประมาณ 10 ปีที่แล้วบางทีฉันอาจจะพบว่าเร็วขึ้น)

แน่นอนถ้าคุณใช้ "รั้งที่ท้ายบรรทัด" มันจะลดบรรทัดพิเศษที่เกิดขึ้น แต่โดยส่วนตัวแล้วฉันไม่ชอบสไตล์นั้น (ฉันใช้มันในที่ทำงานและพบว่ามันไม่เป็นที่พอใจน้อยกว่าที่คาดไว้ แต่ก็ยังไม่เป็นที่พอใจเล็กน้อย)

ฉันประทับใจและถ่อมตนว่าเพื่อนร่วมงานด้านการเขียนโปรแกรมคอมพิวเตอร์ของคุณ (คุณมาก) ไม่กลัวกับข้อผิดพลาดที่อาจเกิดขึ้นเมื่อคุณข้ามการจัดฟันในบล็อกบรรทัดเดียว

ฉันคิดว่ามันไม่ได้ฉลาด ฉันทำผิดพลาดไปหลายครั้งแล้ว ฉันได้แก้ไขข้อผิดพลาดของผู้อื่นเกี่ยวกับเรื่องนี้ ฉันดูซอฟต์แวร์ที่มีข้อบกพร่องด้วยเหตุนี้ (RDP ไปยังเครื่องที่ใช้ VS2002 และแบบอักษรหน้าต่างการดูของคุณจะไม่มีประสิทธิภาพ)

หากฉันดูความผิดพลาดทั้งหมดที่ฉันทำซึ่งสามารถหลีกเลี่ยงได้ด้วยการเปลี่ยนรูปแบบการเขียนโปรแกรมรายการนั้นยาวมาก หากฉันไม่ได้เปลี่ยนวิธีการของฉันในแต่ละกรณีเหล่านี้ฉันอาจจะไม่เคยทำให้มันเป็นโปรแกรมเมอร์ อีกครั้งฉันเดาว่าฉันไม่ฉลาด เพื่อชดเชยฉันเป็นผู้ใช้งานเครื่องมือจัดฟันอย่างแข็งขันในบล็อกแถวเดียวเป็นเวลานาน

ที่กล่าวว่าบางสิ่งมีการเปลี่ยนแปลงในโลกที่ทำให้ "เจ้าจะใช้เครื่องมือจัดฟันในบล็อกบรรทัดเดียว" วันนี้มีความเกี่ยวข้องน้อยกว่าเมื่อโมเสสนำมันมาให้เรา:

• ภาษายอดนิยมบางภาษาทำให้ปัญหาหายไปโดยทำให้คอมพิวเตอร์อ่านการเยื้องเช่นเดียวกับที่โปรแกรมเมอร์ทำ (เช่น Python)

• โปรแกรมแก้ไขของฉันจะจัดรูปแบบโดยอัตโนมัติสำหรับฉันดังนั้นโอกาสที่ฉันจะเข้าใจผิดโดยการเยื้องจึงลดลงมาก

• TDDหมายความว่าถ้าฉันแนะนำบั๊กเพราะฉันสับสนโดยบล็อกบรรทัดเดียวฉันมีแนวโน้มที่จะค้นพบข้อผิดพลาดได้อย่างรวดเร็ว

• การสร้างใหม่และการใช้ภาษาหมายถึงการบล็อกของฉันนั้นสั้นกว่ามากและการบล็อกแบบบรรทัดเดียวเกิดขึ้นบ่อยกว่าที่เคยทำ ด้วยสมมุติฐานว่าด้วยแอปพลิเคชั่นที่โหดเหี้ยมของ ExtractMethod ฉันอาจมีเพียงบล็อกบรรทัดเดียวในโปรแกรมทั้งหมดของฉัน (ฉันสงสัยว่าจะมีลักษณะอย่างไร)

ในความเป็นจริงมีประโยชน์ที่แตกต่างกันสามารถสร้างการจัดฟันอย่างไร้ความปราณีและละเว้นการจัดฟันบนบล็อกบรรทัดเดียว: เมื่อคุณเห็นวงเล็บปีกกาสัญญาณเตือนเล็ก ๆ สามารถไปที่หัวของคุณว่า "ความซับซ้อนที่นี่! ระวัง!" ลองคิดดูว่านี่เป็นบรรทัดฐานหรือไม่:

if (condition) Foo();   // normal, everyday code

if (condition) 
{
    // something non-trivial hapening; pay attention!
    Foo();
    Bar();
}

ฉันเปิดใจกับความคิดในการเปลี่ยนรูปแบบการเขียนรหัสของฉันเป็นแบบ "บล็อกบรรทัดเดียวอาจไม่มีเครื่องหมายปีกกา" หรือ "ถ้าคุณสามารถวางบล็อกไว้ในบรรทัดเดียวกันกับเงื่อนไขและทั้งหมดนั้นพอดีภายใน 80 ตัวอักษร ละเว้นการจัดฟัน " เราจะเห็น

จากการประชุมทั้งสาม:

if(addCurleyBraces()) bugFreeSofware.hooray();

และ:

if(addCurleyBraces())
    bugFreeSofware.hooray();

และ (ซึ่งแสดงถึงสไตล์การเยื้องใด ๆ โดยใช้การเปิดและวงเล็บปีกกาปิด):

if(addCurleyBraces()) {
    bugFreeSofware.hooray();
}

ฉันชอบอันสุดท้ายเป็น:

• ฉันพบว่าการอ่าน if-statement ง่ายกว่าถ้าอ่านด้วยวิธีที่เหมือนกันทั้งหมด
• มันอาจทำให้ซอฟต์แวร์มีความทนทานและปราศจากข้อผิดพลาดเล็กน้อย อย่างไรก็ตามเครื่องมือแก้ไขข้อความ IDE และข้อความขั้นสูงที่ทันสมัยทั้งหมดมีคุณสมบัติการเยื้องอัตโนมัติที่ดีซึ่งฉันคิดว่าทุกคนควรใช้ตราบใดที่มันไม่ได้ทำให้การจัดรูปแบบความคิดเห็นหรือมาตรฐานของทีมขัดข้อง (ในกรณีส่วนใหญ่ และแบ่งปันกับทีม) จุดของฉันที่นี่คือถ้าเยื้องทำอย่างถูกต้องความเสี่ยงของการแนะนำข้อผิดพลาดลดลงเล็กน้อย
• ฉันชอบการแสดงออกแบบบูลีนและคำสั่งที่จะดำเนินการในบรรทัดที่แตกต่างกัน ฉันชอบที่จะสามารถทำเครื่องหมายแถวเพื่อการดีบัก แม้ว่าฉันจะใช้ IDE ที่ฉันอาจทำเครื่องหมายคำสั่งและขั้นตอนมันเป็นการดำเนินการแบบโต้ตอบและฉันอาจลืมที่ฉันเริ่มที่จะแก้จุดบกพร่องหรืออย่างน้อยก็จะทำให้ฉันมีเวลามากขึ้นที่จะก้าวผ่านรหัสหลาย ๆ ครั้ง (ตามที่ฉันต้องทำเครื่องหมายตำแหน่งด้วยตนเองในแต่ละครั้งระหว่างการดีบัก)

อาร์กิวเมนต์หลักของคุณต่อการใช้วงเล็บปีกกาคือพวกเขาใช้บรรทัดเพิ่มเติมและพวกเขาต้องการการเยื้องเพิ่มเติม

เส้นเป็นอิสระ (เกือบ) ลดจำนวนบรรทัดในรหัสของคุณไม่ควรมีวัตถุประสงค์

และการเยื้องเป็นอิสระจากการใช้รั้ง ในตัวอย่างการ 'ใช้' ของคุณฉันยังคิดว่าคุณควรจะเยื้องพวกเขาแม้ว่าคุณจะไม่ใส่เครื่องมือจัดฟัน

ฉันเป็นผู้เชื่อที่แข็งแกร่งในการเขียนโค้ดที่เป็นระเบียบและรัดกุม แต่ฉันจะใช้เครื่องมือจัดฟันแบบหยิก ฉันพบว่าพวกเขาเป็นวิธีที่สะดวกในการดูขอบเขตอย่างรวดเร็วซึ่งมีรหัสบรรทัดใดบรรทัดหนึ่งอยู่ ไม่มีความกำกวมเพียง แต่กำหนดไว้ต่อหน้าคุณอย่างชัดเจน

บางคนอาจบอกว่าเป็นกรณีของการตั้งค่า แต่ฉันพบว่าการไหลแบบลอจิคัลของโปรแกรมง่ายต่อการติดตามถ้ามันสอดคล้องกันภายในและฉันไม่เชื่อว่ามันสอดคล้องกับการเขียนคำสั่ง IF แบบนี้

if(x < y)
    x = y;
else
    y = x;

และอีกเช่นนี้

if(x < y)
{
    x = y;
    x++;
}
else
{
    y = x;
    y++;
}

ฉันชอบที่จะเลือกสไตล์ทั่วไปและติดกับมัน :)

หนึ่งในปัญหาหลักคือเมื่อคุณมีภูมิภาคของสมุทรหนึ่งและไม่ใช่หนึ่งสมุทรพร้อมกับแยกออกจาก statment ควบคุม ( for, ifคุณมีอะไร) และจุดสิ้นสุดของกฎหมาย

ตัวอย่างเช่น:

for (...)
{
  for (...)
    for (...) 
    {
      // a couple pages of code
    }
  // which for block is ending here?  A good text editor will tell you, 
  // but it's not obvious when you're reading the code
}

ฉันเคยเป็นผู้สนับสนุนที่ยิ่งใหญ่ของ "การจัดฟันแบบโค้งเป็นต้อง!" แต่ตั้งแต่ใช้การทดสอบหน่วยฉันพบว่าการทดสอบหน่วยของฉันปกป้องคำสั่งที่ไม่รัดกุมจากสถานการณ์เช่น:

if (foo)
    snafu();
    bar();

ด้วยการทดสอบหน่วยที่ดีฉันสามารถละเว้นวงเล็บปีกกาได้อย่างมั่นใจสำหรับคำสั่งง่ายๆเพื่อปรับปรุงการอ่าน (ใช่ที่สามารถเป็นอัตนัย)

อีกวิธีหนึ่งสำหรับสิ่งที่กล่าวมาข้างต้นฉันมีแนวโน้มที่จะอินไลน์ที่จะมีลักษณะ:

if (foo) snafu();

ด้วยวิธีนี้นักพัฒนาที่ต้องการเพิ่มแถบ () ลงในเงื่อนไขจะมีแนวโน้มที่จะรับรู้ถึงการขาดเครื่องมือจัดฟันแบบโค้งและเพิ่มพวกเขา

ใช้วิจารณญาณส่วนตัว

if (foo)
  bar();

ไม่เป็นไร นอกเสียจากว่าคุณจะกังวลเกี่ยวกับสิ่งที่วางไว้ในลักษณะนี้ในภายหลัง:

if (foo)
  bar();
  baz();

หากคุณไม่กังวลเกี่ยวกับปัญญาอ่อนคุณก็สบายดี (ฉันไม่ใช่ - หากพวกเขาไม่สามารถรับรหัสไวยากรณ์พื้นฐานได้นั่นเป็นปัญหาขั้นต่ำที่สุด)>

ในการแลกเปลี่ยนมันสามารถอ่านได้มากขึ้น

เวลาที่เหลือ:

if (foo) {
  bar();
  baz();
}

ซึ่งเป็นที่โปรดปรานของฉันตราบใดที่ฉันจำได้ นอกจากนี้:

if (foo) {
  bar();
  baz();
} else {
  qux();
}

ได้ผลสำหรับฉัน

พื้นที่แนวตั้งโดยตัวมันเองนั้นไม่เกี่ยวข้องกันมาก รั้งเปิดในบรรทัดด้วยตัวเองเพียงแค่หยุดการสนทนาสำหรับองค์ประกอบวากยสัมพันธ์จนกระทั่งดวงตาของคุณเคลื่อนลงไปที่บรรทัดถัดไป ไม่ใช่สิ่งที่ฉันชอบ

โอเคนี่เป็นคำถามเก่าที่ตอบไปถึงความตาย ฉันมีสิ่งที่จะเพิ่ม

ก่อนอื่นฉันต้องพูดว่าใช้พื้นพรม พวกเขาสามารถช่วยให้อ่านง่ายและสามารถอ่านได้ (สำหรับตัวคุณเองและคนอื่น ๆ !) ควรจะสูงมากในรายการลำดับความสำคัญของคุณเว้นแต่ว่าคุณกำลังเขียนประกอบ รหัสไม่สามารถอ่านได้เสมอนำไปสู่ข้อบกพร่อง หากคุณพบว่าเครื่องมือจัดฟันทำให้รหัสของคุณใช้พื้นที่มากเกินไปวิธีการของคุณอาจยาวเกินไป วิธีการส่วนใหญ่หรือทั้งหมดควรพอดีกับความสูงของหน้าจอเดียวหากคุณทำถูกต้องและ Find (F3) เป็นเพื่อนของคุณ

ตอนนี้สำหรับการเพิ่มของฉัน: มีปัญหากับสิ่งนี้:

if (foo) bar();

ลองตั้งค่าเบรกพอยต์ที่จะกดก็ต่อเมื่อ bar () กำลังทำงาน คุณสามารถทำสิ่งนี้ใน C # โดยวางเคอร์เซอร์บนโค้ดครึ่งหลัง แต่นั่นไม่ชัดเจนและเป็นความเจ็บปวดเล็กน้อย ใน C ++ คุณไม่สามารถทำได้เลย หนึ่งในนักพัฒนาอาวุโสที่สุดของเราที่ทำงานกับรหัส C ++ ยืนยันที่จะแยกคำสั่ง 'if' ออกเป็นสองบรรทัดด้วยเหตุผลนี้ และฉันเห็นด้วยกับเขา

ดังนั้นทำสิ่งนี้:

if (foo)
{
    bar(); //It is easy to put a breakpoint here, and that is useful.
}

เพื่อที่จะป้องกันไม่ให้มีการจัดฟันด้วยการใช้รหัสพื้นที่มากฉันใช้เทคนิคที่แนะนำในหนังสือรหัสเสร็จสมบูรณ์ :

if (...) {
    foo();
    bar();
}
else {
    ...
}

สมมติว่าคุณมีรหัส:

if (foo)
    bar();

แล้วมีคนอื่นมาเพิ่ม:

if (foo)
    snafu();
    bar();

ตามวิธีที่เขียนไว้แถบ (); ถูกดำเนินการโดยไม่มีเงื่อนไข การใส่วงเล็บปีกกาไว้ด้วยจะช่วยป้องกันข้อผิดพลาดประเภทนี้ได้ ควรเขียนรหัสในลักษณะที่จะทำผิดพลาดยากหรือเป็นไปไม่ได้ หากฉันทำการตรวจสอบโค้ดและเห็นวงเล็บปีกกาที่ขาดหายไปโดยเฉพาะอย่างยิ่งในหลาย ๆ บรรทัดฉันจะสร้างข้อบกพร่อง ในกรณีที่มันเป็นธรรมให้มันไว้ในบรรทัดเดียวเพื่อให้โอกาสในการทำข้อผิดพลาดดังกล่าวจะถูกเก็บไว้ให้น้อยที่สุดอีกครั้ง

การลดจำนวนบรรทัดไม่ใช่ข้อโต้แย้งที่ดีในการทำเครื่องหมายปีกกา หากวิธีการของคุณมีขนาดใหญ่เกินไปก็อาจจะได้รับการ refactored เป็นชิ้นเล็ก ๆ หรือปรับโครงสร้าง การทำเช่นนั้นจะช่วยเพิ่มความสามารถในการอ่านได้มากกว่าแค่การจัดฟัน

ฉันจะละเว้นพวกเขาเมื่อเหมาะสมเช่นในตัวอย่างแรกของคุณ รหัสที่สะอาดและรัดกุมที่ฉันสามารถดูและเข้าใจได้โดยการเหลือบไปที่นั้นง่ายต่อการบำรุงรักษาดีบักและเข้าใจได้ดีกว่ารหัสที่ฉันต้องเลื่อนและอ่านทีละบรรทัด ฉันคิดว่าโปรแกรมเมอร์ส่วนใหญ่จะเห็นด้วยกับเรื่องนี้

มันง่ายที่จะหลุดพ้นจากมือหากคุณเริ่มทำหลาย ๆ คำสั่งถ้าทำอย่างอื่น แต่ฉันคิดว่าโปรแกรมเมอร์ส่วนใหญ่น่าจะสามารถบอกตำแหน่งที่จะวาดเส้นได้

ฉันเห็นมันชนิดเช่นอาร์กิวเมนต์สำหรับVSif ( foo == 0 ) if ( 0 == foo )หลังอาจป้องกันข้อผิดพลาดสำหรับโปรแกรมเมอร์ใหม่ (และอาจเป็นครั้งคราวสำหรับทหารผ่านศึก) ในขณะที่อดีตจะง่ายต่อการอ่านและเข้าใจได้อย่างรวดเร็วเมื่อคุณรักษารหัส

เวลาส่วนใหญ่จะฝังอยู่ในมาตรฐานการเข้ารหัสไม่ว่าจะสำหรับ บริษัท หรือโครงการ FOSS

ท้ายที่สุดแล้วคนอื่นจะต้องคร่ำครวญโค้ดของคุณและมันเป็นช่วงเวลาที่สำคัญสำหรับนักพัฒนาแต่ละคนที่จะต้องเข้าใจถึงรูปแบบเฉพาะของส่วนของรหัสที่พวกเขากำลังทำงานอยู่

ลองจินตนาการดูว่ามีใครบางคนกำลังเข้าร่วมระหว่าง Python กับภาษา Cish มากกว่าหนึ่งครั้งต่อวัน ... การเยื้องของ Python เป็นส่วนหนึ่งของบล็อกไซแมนติกของภาษา

ข้อผิดพลาดด้านความปลอดภัยมากขึ้น - อีกหนึ่งข้อผิดพลาดที่คุณอาจไม่ต้องแก้ไข

โดยส่วนตัวแล้วฉันรู้สึกปลอดภัยมากขึ้นถ้าบล็อคทั้งหมดของฉันถูกห่อเป็นรูปโค้ง แม้สำหรับหนึ่งตอร์ปิโดสิ่งเหล่านี้เป็นสัญลักษณ์ที่ง่ายที่ป้องกันข้อผิดพลาดได้อย่างง่ายดาย มันทำให้โค้ดอ่านง่ายขึ้นในแง่ที่ว่าคุณเห็นสิ่งที่อยู่ในบล็อกอย่างชัดเจนเพื่อไม่ให้เนื้อความของบล็อกสับสนโดยใช้ข้อความต่อไปนี้นอกบล็อก

ถ้าฉันมีหนึ่งซับฉันมักจะจัดรูปแบบดังต่อไปนี้:

if( some_condition ) { do_some_operation; }

หากบรรทัดนั้นยุ่งยากเกินไปให้ใช้วิธีต่อไปนี้:

if( some_condition )
{
    do_some_operation;
}