เครื่องมือจัดฟันจำเป็นในข้อความสั่งบรรทัดเดียวใน JavaScript หรือไม่


163

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

มีสิ่งใดบ้างที่ทำให้เป็นความคิดที่ดีที่จะล้อมรอบข้อความทั้งหมดในวงเล็บปีกกาใน JavaScript?

ฉันถามเพราะทุกคนดูเหมือนจะทำ


5
หมายเหตุ: เฉพาะข้อความแรกที่สมมติว่ามีขอบเขตแม้ว่าคุณจะมีหลายข้อความในหนึ่งบรรทัดดังนั้นมันจึงไม่ใช่ "ข้อความหนึ่งบรรทัด" แต่เป็นข้อความเดี่ยว
Kris Ivanov

1
คุณอาจคิดถึงปัญหาที่อธิบายไว้ในคำตอบนี้
Blorgbeard ออกเมื่อ

@Blorgbeard: ไม่จริงฉันตอบกลับไปแล้วเมื่อไม่นานมานี้
หอคอย

ฉันเห็นแล้ว ไม่เป็นไร :) :)
Blorgbeard ออก

นี่คือคำตอบของคุณ: medium.com/@jonathanabrams/…
Erwan Legrand

คำตอบ:


204

ไม่

แต่พวกเขาจะแนะนำ หากคุณเคยขยายคำสั่งคุณจะต้องพวกเขา

นี้ถูกต้องสมบูรณ์

if (cond) 
    alert("Condition met!")
else
    alert("Condition not met!")

อย่างไรก็ตามขอแนะนำให้คุณใช้เครื่องมือจัดฟันเสมอเพราะหากคุณ (หรือคนอื่น) ขยายคำแถลงมันจะต้อง

การปฏิบัติแบบเดียวกันนี้จะตามมาในภาษารูปแบบไวยากรณ์ทั้งหมดของ C พร้อมการค้ำยัน C, C ++, Java, แม้กระทั่ง PHP ทั้งหมดรองรับคำสั่งหนึ่งบรรทัดโดยไม่ต้องใส่เครื่องหมายวงเล็บ คุณต้องตระหนักว่าคุณกำลังบันทึกอักขระสองตัวเท่านั้นและด้วยรูปแบบการค้ำยันของบางคนคุณไม่ได้บันทึกบรรทัด ฉันชอบสไตล์รั้งเต็ม (เช่นดังนี้) ดังนั้นจึงมีแนวโน้มที่จะยาวขึ้นเล็กน้อย ข้อดีก็คือการแลกเปลี่ยนกันเป็นอย่างดีกับความจริงที่ว่าคุณมีความชัดเจนในการอ่านรหัส

if (cond) 
{
    alert("Condition met!")
}
else
{
    alert("Condition not met!")
}

28
+1, คำตอบที่ให้ข้อมูล โดยส่วนตัวแล้วฉันไม่เคยพบว่ามีประโยชน์ในการทำสิ่งนี้ "แนะนำ" ฉันไม่เคยเขียนรหัสไพ ธ อนดังนั้นฉันจึงไม่เพียงแค่แทรกสิ่งต่าง ๆ และคาดหวังว่าการเยื้องจะมีความสำคัญ ถ้าฉันเพิ่มคำสั่งฉันยังเพิ่มการจัดฟัน เสมอ. จำไม่ได้ซักครั้งแล้วมันก็กัดฉัน ไม่ได้อยู่ใน C ไม่ใช่ใน C # ไม่ใช่ใน JavaScript
Jakob

16
@ Kirk: Douglas Crockford แนะนำให้มัน ฉันยอมรับว่าเป็นการตัดสินใจส่วนตัว แต่เมื่อทำงานในกลุ่มมันง่ายกว่าที่จะพิมพ์เครื่องมือจัดฟัน
Josh K

10
@ Josh, Crockford พูดดี นั่นจะต้องเป็นคำพูดสุดท้าย ;) (ล้อเล่น) ประเด็นก็คือความเป็นส่วนตัวของประเด็นนี้ครอบคลุมทั่วภาษา C เหมือนกันทั้งหมดและความคิดเห็นที่แข็งแกร่งสามารถพบได้ทั่ว (สำหรับทั้งสองตำแหน่ง)
Kirk Woll

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

4
เป็นวิธีปฏิบัติที่ดีที่จะใช้เครื่องมือจัดฟัน {} ตามที่ @Ax บอกว่ามีข้อผิดพลาดมากขึ้นถ้าคุณปล่อยให้พวกเขาออก Apple ยังมีข้อผิดพลาดใน SSL / TLS ของ iOS เพราะพวกเขาไม่ได้ใช้เครื่องหมายปีกกา
Keenan Lidral-Porter

94

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

var a;
var b;
var c;

//Indenting is clear
if (a===true)
  alert(a); //Only on IF
alert(b); //Always

//Indenting is bad
if (a===true)
  alert(a); //Only on IF
  alert(b); //Always but expected?

//Nested indenting is clear
if (a===true)
  if (b===true)
    alert(a); //Only on if-if
alert (b); //Always

//Nested indenting is misleading
if (a===true)
  if (b===true)
    alert(a); //Only on if-if
  alert (b); //Always but expected as part of first if?

//Compound line is misleading
//b will always alert, but suggests it's part of if
if (a===true) alert(a);alert(b); 
else alert(c); //Error, else isn't attached

แล้วมีความสามารถในการขยายเพิ่มเติม:

//Problematic
if (a===true)
  alert(a);
  alert(b); //We're assuming this will happen with the if but it'll happen always
else       //This else is not connected to an if anymore - error
  alert(c);

//Obvious
if (a===true) {
  alert(a); //on if
  alert(b); //on if
} else {
  alert(c); //on !if
} 

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


4
if (a===true) alert(a);นั่นเป็นเหตุผลที่เราควรจะใช้มันเป็นหนึ่งซับ: ตอนนี้มันชัดเจน!
João Pimentel Ferreira

1
การใช้วงเล็บปีกกาซ้ายซ้ายและวงเล็บปีกกาขวาทำให้เงื่อนไขนั้นชัดเจน สำหรับผู้ฝันในหมู่พวกเราก็เรียกว่านกบินซ้ายและขวา
HalfMens

61

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

ตัวอย่างเช่นคำถามจะถามว่ามันใช้ได้หรือไม่:

 if (condition) statement;

มันไม่ได้ถามว่ามันจะโอเคไหม

 if (condition)
   statement;

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

สไตล์การเขียนโค้ดของฉันคือห้ามใช้เครื่องหมายวงเล็บยกเว้นว่าโค้ดนั้นเป็นบล็อก และไม่เคยใช้หลายคำสั่งในบรรทัดเดียว (คั่นด้วยเครื่องหมายอัฒภาค) ฉันพบว่าง่ายต่อการอ่านและชัดเจนและไม่เคยมีปัญหาในการกำหนดงบ 'ถ้า' ดังนั้นการใช้วงเล็บบนคำสั่งเงื่อนไขเดียวหากต้องการเงื่อนไข 3 บรรทัด แบบนี้:

 if (condition) {
   statement;
 }

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

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


1
ฉันมักจะรู้สึกว่าควรมีเครื่องมือจัดฟันอยู่เสมอ ... แต่ตอนนี้ฉันคิดใหม่ คุณมีไกด์สไตล์airbnbอยู่เคียงข้างคุณ!
senderle

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

1
การเพิ่ม 2 บรรทัดสำหรับวงเล็บแต่ละอันเพื่อล้อมรอบแถลงการณ์บรรทัดเดียวของคุณนั้นไม่ได้มีค่าใช้จ่ายมากนักเมื่อเทียบกับความเสียหายที่อาจเกิดขึ้นจากนักพัฒนาที่ระมัดระวังอย่างมาก - ดูแลรหัสของคุณ ตัวคุณเองสามารถเป็นนักพัฒนาที่ยอดเยี่ยมที่มีทักษะในตำนาน แต่คุณไม่สามารถคิดได้ว่าเพื่อนร่วมงานของคุณเป็นใคร จูบห่อสิ่งต่าง ๆ ด้วยบริบทและทำให้เป็นเรื่องง่ายที่สุดเท่าที่จะเป็นไปได้สำหรับคนอื่น ๆ หรือในที่สุดคุณก็จะเดือดร้อน
Maciej Tokarz

@senderle กฎ eslint ในการควบคุมสามารถพบได้ที่นี่: eslint.org/docs/rules/curly#multi /*eslint curly: ["error", "multi"]*/
silkfire

15

ในทางเทคนิคไม่มี แต่อย่างแน่นอนใช่ !!!

ลืมเรื่อง "มันเป็นความชอบส่วนตัว", "รหัสจะทำงานได้ดี", "มันใช้งานได้ดีสำหรับฉัน", "อ่านง่ายขึ้น" yada yada BS นี้ได้อย่างง่ายดายอาจนำไปสู่ปัญหาร้ายแรงมากถ้าคุณทำผิดพลาดและฉันเชื่อว่ามันเป็นเรื่องง่ายมากที่จะทำผิดพลาดเมื่อคุณได้รับการเข้ารหัส (Do not belive ?, ตรวจสอบที่มีชื่อเสียงแอปเปิ้ลไปที่จะล้มเหลวข้อผิดพลาด )

อาร์กิวเมนต์: "มันเป็นความชอบส่วนตัว"

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

อาร์กิวเมนต์: "รหัสจะทำงานได้ดี"

ดังนั้นรหัสสปาเก็ตตี้ไม่! มันหมายความว่าไม่เป็นไรที่จะสร้างมันขึ้นมา?

อาร์กิวเมนต์: "มันทำงานได้ดีสำหรับฉัน"

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

if (condition) 
    DoSomething();
SomethingElse();

หรือเพิ่ม 'SomethingMore' และไม่ได้สังเกตว่าจะไม่ถูกเรียก (แม้ว่าการเยื้องจะมีความหมายเป็นอย่างอื่น):

if (condition)
  DoSomething();
  SomethingMore();

นี่คือตัวอย่างชีวิตจริงของฉัน มีคนต้องการเปลี่ยนการบันทึกทั้งหมดเพื่อให้พวกเขาเรียกใช้ find & replace "console.log"=> //"console.log":

if (condition) 
   console.log("something");
SomethingElse();

เห็นปัญหาไหม

แม้ว่าคุณจะคิดว่า "สิ่งเหล่านี้ช่างน่ารำคาญเหลือเกินฉันก็จะไม่ทำอย่างนั้น"; จำไว้ว่าจะมีสมาชิกในทีมที่มีทักษะการเขียนโปรแกรมด้อยกว่าคุณเสมอ (หวังว่าคุณจะไม่ได้แย่ที่สุดในทีม!)

อาร์กิวเมนต์: "อ่านง่ายกว่า"

ถ้าฉันได้เรียนรู้อะไรเกี่ยวกับการเขียนโปรแกรมมันเป็นสิ่งที่เรียบง่ายซับซ้อนมากอย่างรวดเร็ว เป็นเรื่องธรรมดามากที่จะ:

if (condition) 
    DoSomething();

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

if (a != null)
   if (condition) 
      DoSomething();
   else
      DoSomethingElse(); 
      DoSomethingMore();
else 
    if (b == null)
         alert("error b");
    else 
         alert("error a");

และเปรียบเทียบกับสิ่งนี้:

 if (a != null) {
    if (condition) { 
       DoSomething();
    }
    else {
       DoSomethingElse();
       DoSomethingMore();
    }
 } else if (b == null) {
    alert("error b");
 } else {
    alert("error a");
 }

PS: คะแนนโบนัสไปที่ผู้สังเกตเห็นข้อผิดพลาดในตัวอย่างข้างต้น


2
ข้อผิดพลาดที่ชัดเจนคือ DoSomethingMore (); แต่ก็ยังมีข้อผิดพลาดอื่น หาก a เป็นโมฆะและ b เป็นโมฆะคุณจะได้รับ "error b" เท่านั้นคุณจะไม่ได้รับ "error a"
rocketsarefast

จากตัวอย่างของคุณทีมพัฒนาของคุณไม่ทราบวิธีการใช้รหัสการจัดฟันจะไม่ช่วยพวกเขา ...
Carlos ABS

ตัวอย่างบางส่วนมาจากทีมนักพัฒนาของ Apple
Caner

13

ไม่มีปัญหาการบำรุงรักษา!

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

if (a > 1)
 alert("foo"),
 alert("bar"),
 alert("lorem"),
 alert("ipsum");
else
 alert("blah");

นี่เป็นรหัสที่ถูกต้องที่จะทำงานเหมือนที่คุณคาดหวัง!


2
อย่าคุณหมายถึงif, elseและalertและไม่ได้If, ElseและAlert?
Anish Gupta

ว้าวฉันไม่รู้เรื่องนี้ขอขอบคุณที่แจ้งให้ฉันทราบ! ดูเหมือนว่าคนส่วนใหญ่ไม่เห็นรายละเอียดที่สำคัญนี้
Hendeca

13
ในขณะที่การทำงานใน JavaScript มันเป็นมากกว่าฉันทำไมคุณต้องการที่จะทำเช่นนั้น ฉันเดาว่าผู้พัฒนาส่วนใหญ่ไม่ได้ตระหนักถึงสิ่งนี้ (ตัวเองรวมถึงก่อนที่จะอ่านข้อความนี้) ซึ่งฉันสงสัยว่าจะกลายเป็นปัญหาด้านการบำรุงรักษาของผู้พัฒนาอย่างรวดเร็ว บางครั้งวิธีที่ฉลาดที่สุดก็ไม่ใช่วิธีที่ดีที่สุด
Simon

14
นี่มันช่างน่ากลัว ถ้ามีคนเพิ่มคำสั่งและลืมที่จะหันอัฒภาคลงในเครื่องหมายจุลภาคในตอนที่สองให้กับคำสั่งสุดท้ายในบล็อกคุณมีข้อผิดพลาดที่อาจจะเป็นจริงยากที่จะจุดเพราะจุลภาคและอัฒภาคในตอนท้ายของทางสายการดูมากเกินไป คล้ายคลึงกัน
Ingo Bürk

1
ฉันชอบวิธี"Hemingwayian" : สะอาดมาก และไม่มีที่ว่างระหว่างifและ(เช่นif(true) doSomething();
58

8

ไม่มีเหตุผลการเขียนโปรแกรมที่จะใช้วงเล็บปีกกาบนงบบรรทัดเดียว

นี่เป็นเพียงการตั้งค่าและการอ่านโค๊ดเท่านั้น

รหัสของคุณจะไม่ผิดเพราะมัน


7

นอกเหนือไปจากเหตุผลที่กล่าวถึงโดย @ Josh K (ซึ่งยังนำไปใช้ Java, C ฯลฯ ) ปัญหาพิเศษใน JavaScript คือการแทรกอัฒภาคอัตโนมัติ จากตัวอย่างของ Wikipedia:

return
a + b;

// Returns undefined. Treated as:
//   return;
//   a + b;

ดังนั้นสิ่งนี้อาจให้ผลลัพธ์ที่ไม่คาดคิดหากใช้เช่นนี้:

if (x)
   return
   a + b;

มันไม่ได้ดีไปกว่าการเขียน

if (x) {
   return
   a + b;
}

แต่นี่อาจเป็นข้อผิดพลาดง่ายขึ้นเล็กน้อยในการตรวจสอบ (?)


ตัวอย่างทั้งหมดเหล่านี้ดูน่ากลัวสำหรับฉันเว้นแต่ผู้เขียนจะชั่วคราวและจ่ายเงินตามบรรทัดหรือจนกว่าจะได้ผล
Cees Timmerman

6

มันเป็นเรื่องของสไตล์ แต่วงเล็บปีกกาเป็นสิ่งที่ดีสำหรับการป้องกันเป็นไปได้ห้อยอื่น


4

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

แม้แต่ "กรณีที่ไม่ดี" ก็สามารถระบุได้อย่างรวดเร็ว (และคงที่) เนื่องจากการยกเลิกการควบคุมการไหล แนวคิด / โครงสร้าง“ กฎ” นี้ใช้กับหลายภาษา

if (x)
    return y;
    always();

แน่นอนว่านี่เป็นเหตุผลว่าทำไมคนเราถึงใช้ linter ..


3

นี่คือเหตุผลที่แนะนำ

สมมติว่าฉันเขียน

if(someVal)
    alert("True");

จากนั้นผู้พัฒนารายต่อไปก็มาพูดว่า "โอ้ฉันต้องทำอย่างอื่น" ดังนั้นพวกเขาจึงเขียน

if(someVal)
    alert("True");
    alert("AlsoTrue");

ในขณะนี้คุณสามารถเห็น "AlsoTrue" ได้เสมอเพราะผู้พัฒนารายแรกไม่ได้ใช้เครื่องมือจัดฟัน


ไม่ถูกต้องคุณพลาด 'else': if (someVal) alert ("True"); การแจ้งเตือนอื่น ("AlsoTrue"); จะถูกต้อง ฉันจะไม่ใช้เพราะฉันชอบ {} เพราะอ่านได้ดีกว่ามาก
Gerrit B

1
ฮะ? ฉันไม่มีคำสั่งอื่น ฉันกำลังบอกว่าหากไม่มีเครื่องหมายปีกกาก็สามารถนำไปสู่ข้อบกพร่องหากมีคนเพิ่มบรรทัดใหม่ ฉันคิดว่าคุณไม่เข้าใจประเด็นของฉัน
Amir Raminfar

ฉันคิดว่าสิ่งที่เขาพูดคือบรรทัดที่ 2 จะถูกประหารชีวิตไม่ว่าจะเกิดอะไรขึ้น คำสั่ง If ที่ไม่มีเครื่องหมายวงเล็บปีกกาสามารถดำเนินการ 1 บรรทัดเท่านั้น
PostCodeism

3

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

function a(b){if(c){d}else{e}} //ok  
function a(b){if(c)d;else e}   //ok

แน่นอนคุณต้องแทนที่วงเล็บปิดด้วยเครื่องหมายอัฒภาคหากไม่ได้ตามด้วยวงเล็บปีกกาปิดอื่น ๆ

ฟังก์ชั่นจะต้องไม่ลงท้ายด้วยเครื่องหมายจุลภาค

var a,b=function()c;  //ok *but not in Chrome
var b=function()c,a;  //error  

ทดสอบบน Chrome และ FF


2

มักพบว่า

if(valid) return;

ตาฉันง่ายกว่า

if(valid) {
  return;
}

ยังมีเงื่อนไขเช่น

(valid) ? ifTrue() : ifFalse();

อ่านง่ายกว่า (ความเห็นส่วนตัวของฉัน) มากกว่า

if(valid) {
  ifTrue();
} else {
  ifFalse();
}

แต่ฉันเดาว่ามันจะเป็นสไตล์การเขียนโค้ด


2

ไม่ตอบคำถามโดยตรง แต่ด้านล่างเป็นไวยากรณ์สั้น ๆ เกี่ยวกับเงื่อนไขว่าในหนึ่งบรรทัด

Ex:

var i=true;
if(i){
  dosomething();
}

สามารถเขียนได้เช่นนี้

var i=true;
i && dosomething();

1

มีปัญหามากมายในจาวาสคริปต์ ลองดูที่สถาปนิก JavaScript Douglas Crockford ที่พูดถึงเรื่องนี้ข้อความifดูเหมือนว่าจะใช้ได้ แต่คำสั่งreturnอาจแนะนำปัญหา

return
{
    ok:false;
}
//silent error (return undefined)

return{
    ok:true;
}
//works well in javascript

1

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

คำสั่ง Bracketless ทำงานในเบราว์เซอร์ส่วนใหญ่ แต่ฉันทดสอบว่าวิธีการที่ไม่ยึดติดในความเป็นจริงไม่ทำงานในเบราว์เซอร์บางตัว

ตั้งแต่วันที่ 26 กุมภาพันธ์ 2018 ข้อความนี้ใช้งานได้ใน Pale Moon แต่ไม่ใช่ Google Chrome

function foo()
   return bar;

0

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

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

if (foo) bar();    // I like this. It's also consistent with Python FWIW

แทน

if (foo)
   bar();   // not so good

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

if (foo) {
  bar();    // better
}

จากนั้นง่ายและสอดคล้องกันในการเพิ่มคำสั่งใหม่ด้านบนหรือด้านล่างแถบภายในเนื้อหาของคำสั่ง if

if (foo) {
  bar();    // consistent
  baz();    // easy to read and maintain
}

-1

บางครั้งพวกเขาดูเหมือนจะต้องการ! ฉันไม่อยากจะเชื่อเลย แต่เมื่อวานนี้มันเกิดขึ้นกับฉันในเซสชัน Firebug (Firefox รุ่นล่าสุด 22.0)

if (! my.condition.key)
    do something;

ดำเนินการทำบางสิ่งบางอย่างแม้จะmy.condition.keyเป็นจริง การเพิ่มเครื่องมือจัดฟัน:

if (! my.condition.var) {
    do something;
}

แก้ไขเรื่องนั้น มีตัวอย่างมากมายที่สามารถใช้งานได้โดยไม่ต้องใช้เครื่องมือจัดฟัน แต่ในกรณีนี้มันใช้ไม่ได้

คนที่มีแนวโน้มที่จะนำคำสั่งมากกว่าหนึ่งบนเส้นมากแน่นอนควรจะเสมอใช้วงเล็บแน่นอนเพราะสิ่งที่ต้องการ

if (condition)
    do something; do something else;

หายาก


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

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

-1

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

if(2 == 1){
    if(1 == 2){
        console.log("We will never get here")
    }
} else 
    console.log("We will get here")

รูปแบบ [Qt วงเล็บปีกกา] [1] ต้องการบล็อกทั้งสองด้านของการelseจับคู่การใช้รั้ง - ตัวอย่างนี้จะต้องใช้วงเล็บปีกกาบนelseบล็อกเพื่อผ่านการตรวจสอบรหัส [1]: wiki.qt.io/Qt_Coding_Style#Braces
pixelgrease

ทำไมต้องลงคะแนน? ข้อความข้างต้นมีความถูกต้อง 100%
Johnston

-1

มีวิธีการที่จะบรรลุวงเล็บปีกกาหลายบรรทัดหากคำสั่ง .. (ว้าวอะไรภาษาอังกฤษ .. ) แต่มันเป็นเรื่องน่าเบื่อ:

if(true)
   funcName();
else
   return null;


function funcName(){
  //Do Stuff Here...
}

คุณไม่จำเป็นต้องมีบรรทัดใหม่จำนวนมากเมื่อไม่ใส่เครื่องหมายปีกกา ด้านบนสามารถเขียนได้สองบรรทัดดังนี้: if (true) funcName()และ else return null
phobos
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.