Niềng răng có cần thiết trong câu lệnh một dòng trong JavaScript không?

Tôi đã từng nghe nói rằng việc để các dấu ngoặc nhọn trong các câu lệnh một dòng có thể gây hại trong JavaScript. Tôi không nhớ lý do nữa và một tìm kiếm Google không giúp được gì nhiều.

Có bất cứ điều gì làm cho nó là một ý tưởng tốt để bao quanh tất cả các câu lệnh trong dấu ngoặc nhọn trong JavaScript không?

Tôi đang hỏi, bởi vì mọi người dường như làm như vậy.

Không

Nhưng họ được khuyến khích. Nếu bạn mở rộng tuyên bố, bạn sẽ cần chúng.

Điều này là hoàn toàn hợp lệ

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

Tuy nhiên, rất khuyến khích bạn luôn luôn sử dụng niềng răng vì nếu bạn (hoặc ai đó) mở rộng câu lệnh thì sẽ được yêu cầu.

Thực hành tương tự này theo sau trong tất cả các ngôn ngữ kiểu cú pháp C với giằng. C, C ++, Java, thậm chí PHP đều hỗ trợ câu lệnh một dòng mà không cần dấu ngoặc. Bạn phải nhận ra rằng bạn chỉ lưu hai ký tự và với một số kiểu giằng của một số người, bạn thậm chí không lưu một dòng. Tôi thích một kiểu nẹp đầy đủ (như sau) vì vậy nó có xu hướng dài hơn một chút. Sự đánh đổi được đáp ứng rất tốt với thực tế là bạn có khả năng đọc mã cực kỳ rõ ràng.

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

Có một khía cạnh dễ đọc - trong đó khi bạn có các câu lệnh ghép, nó có thể trở nên rất khó hiểu. Việc thụt lề giúp nhưng không có ý nghĩa gì với trình biên dịch / trình thông dịch.

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

Và sau đó là một khía cạnh mở rộng:

//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
} 

Suy nghĩ rằng nếu bạn luôn có dấu ngoặc thì bạn biết chèn các câu lệnh khác vào trong khối đó.

Câu hỏi hỏi về các tuyên bố trên một dòng. Tuy nhiên, nhiều ví dụ được cung cấp cho thấy lý do không bỏ qua niềng răng dựa trên nhiều câu lệnh. Hoàn toàn an toàn khi không sử dụng dấu ngoặc trên một dòng, nếu đó là kiểu mã hóa bạn thích.

Ví dụ, câu hỏi hỏi liệu điều này có ổn không:

 if (condition) statement;

Nó không hỏi nếu điều này là ok:

 if (condition)
   statement;

Tôi nghĩ rằng bỏ dấu ngoặc ra là thích hợp hơn vì nó làm cho mã dễ đọc hơn với cú pháp ít thừa hơn.

Phong cách mã hóa của tôi là không bao giờ sử dụng dấu ngoặc trừ khi mã là một khối. Và không bao giờ sử dụng nhiều câu lệnh trên một dòng (cách nhau bằng dấu chấm phẩy). Tôi thấy điều này dễ đọc và rõ ràng và không bao giờ có vấn đề về phạm vi 'nếu'. Kết quả là, sử dụng dấu ngoặc trên một câu lệnh if điều kiện sẽ yêu cầu 3 dòng. Như thế này:

 if (condition) {
   statement;
 }

Sử dụng một dòng nếu câu lệnh là thích hợp hơn vì nó sử dụng ít không gian dọc hơn và mã nhỏ gọn hơn.

Tôi sẽ không ép buộc người khác sử dụng phương pháp này, nhưng nó hiệu quả với tôi và tôi không thể không đồng ý nhiều hơn với các ví dụ được cung cấp về cách bỏ dấu ngoặc dẫn đến lỗi mã hóa / phạm vi.

Về mặt kỹ thuật thì không nhưng hoàn toàn khác Có !!!

Hãy quên đi "Đó là sở thích cá nhân", "mã sẽ chạy tốt", "nó đã hoạt động tốt với tôi", "nó dễ đọc hơn" yada yada BS. Điều này có thể dễ dàng dẫn đến những vấn đề rất nghiêm trọng nếu bạn mắc lỗi và tin tôi rằng rất dễ mắc lỗi khi bạn đang viết mã (Đừng tin?, Hãy xem Apple nổi tiếng gặp lỗi ).

Luận điểm: "Đó là sở thích cá nhân"

Không có nó không phải là. Trừ khi bạn là một đội một người đàn ông rời đi trên sao hỏa, không. Hầu hết thời gian sẽ có người khác đọc / sửa đổi mã của bạn. Trong bất kỳ nhóm mã hóa nghiêm túc nào, đây sẽ là cách được đề xuất, vì vậy đó không phải là 'sở thích cá nhân'.

Đối số: "mã sẽ chạy tốt"

Mã spaghetti cũng vậy! Có nghĩa là nó ổn để tạo ra nó?

Luận điểm: "nó đã hoạt động tốt với tôi"

Trong sự nghiệp của tôi, tôi đã thấy rất nhiều lỗi được tạo ra vì vấn đề này. Bạn có thể không nhớ bao nhiêu lần bạn nhận xét 'DoSomething()'và bối rối tại sao 'SomethingElse()'được gọi là:

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

Hoặc đã thêm 'SomethingMore' và không nhận thấy nó sẽ không được gọi (mặc dù vết lõm có nghĩa khác):

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

Đây là một ví dụ thực tế mà tôi đã có. Ai đó muốn bật tất cả các bản ghi để họ chạy find & thay thế "console.log"=> //"console.log":

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

Thấy vấn đề?

Ngay cả khi bạn nghĩ, "những thứ này quá tầm thường, tôi sẽ không bao giờ làm điều đó"; hãy nhớ rằng sẽ luôn có một thành viên trong nhóm có kỹ năng lập trình kém hơn bạn (hy vọng bạn không phải là người kém nhất trong nhóm!)

Luận điểm: "nó dễ đọc hơn"

Nếu tôi đã học được bất cứ điều gì về lập trình, thì đó là những điều đơn giản trở nên rất phức tạp rất nhanh. Điều này rất phổ biến rằng:

if (condition) 
    DoSomething();

biến thành như sau sau khi nó đã được thử nghiệm với các trình duyệt / môi trường / trường hợp sử dụng khác nhau hoặc các tính năng mới được thêm vào:

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

Và so sánh nó với điều này:

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

PS: Điểm thưởng thuộc về người nhận thấy lỗi trong ví dụ trên.

Không có vấn đề bảo trì!

Vấn đề với tất cả các bạn là bạn đặt dấu chấm phẩy ở mọi nơi. Bạn không cần niềng răng xoăn cho nhiều câu lệnh. Nếu bạn muốn thêm một câu lệnh, chỉ cần sử dụng dấu phẩy.

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

Đây là mã hợp lệ sẽ chạy như bạn mong đợi!

Không có lý do lập trình để sử dụng dấu ngoặc nhọn trên các câu lệnh một dòng.

Điều này chỉ đến với sở thích và khả năng đọc của lập trình viên.

Mã của bạn sẽ không bị hỏng vì nó.

Ngoài lý do được đề cập bởi @Josh K (cũng áp dụng cho Java, C, v.v.), một vấn đề đặc biệt trong JavaScript là chèn dấu chấm phẩy tự động . Từ ví dụ Wikipedia:

return
a + b;

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

Vì vậy, điều này cũng có thể mang lại kết quả bất ngờ, nếu được sử dụng như thế này:

if (x)
   return
   a + b;

Nó không thực sự tốt hơn để viết

if (x) {
   return
   a + b;
}

nhưng có lẽ ở đây lỗi dễ phát hiện hơn một chút (?)

Đó là một vấn đề về phong cách, nhưng niềng răng xoăn là tốt để ngăn chặn nguy hiểm có thể khác .

Có rất nhiều câu trả lời hay, vì vậy tôi sẽ không lặp lại, ngoại trừ việc nói quy tắc của tôi, khi niềng răng có thể được bỏ qua: với điều kiện 'quay trở lại' hoặc 'ném' (ví dụ) như là tuyên bố duy nhất của họ . Trong trường hợp này, kiểm soát luồng đã rõ ràng rằng nó chấm dứt:

Ngay cả trường hợp xấu cũng có thể được xác định nhanh chóng (và cố định) do điều khiển luồng kết thúc. Khái niệm / cấu trúc quy tắc này cũng áp dụng cho một số ngôn ngữ.

if (x)
    return y;
    always();

Tất nhiên, đây cũng là lý do tại sao người ta có thể sử dụng một kẻ nói dối ..

Đây là lý do tại sao nó được đề nghị

Hãy nói tôi viết

if(someVal)
    alert("True");

Sau đó, nhà phát triển tiếp theo đến và nói "Ồ, tôi cần phải làm gì khác", vì vậy họ viết

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

Bây giờ, như bạn có thể thấy "Ngoài ra" sẽ luôn đúng, bởi vì nhà phát triển đầu tiên đã không sử dụng niềng răng.

Tôi hiện đang làm việc trên một công cụ khai thác. Ngay cả bây giờ tôi kiểm tra nó trên hai kịch bản lớn. Thực nghiệm tôi phát hiện ra: Bạn có thể loại bỏ các dấu ngoặc nhọn phía sau cho, nếu, khác, trong khi, chức năng * nếu các dấu ngoặc nhọn không bao gồm ';', 'return', 'for', 'if', 'other', 'trong khi', 'làm', 'chức năng'. Không phân biệt ngắt dòng.

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

Tất nhiên bạn cần thay thế nẹp đóng bằng dấu chấm phẩy nếu nó không theo sau trên nẹp đóng khác.

Hàm không được kết thúc bằng dấu phẩy.

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

Đã thử nghiệm trên Chrome và FF.

Luôn luôn thấy rằng

if(valid) return;

trong mắt tôi dễ hơn

if(valid) {
  return;
}

cũng có điều kiện như

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

dễ đọc hơn (ý kiến ​​cá nhân của tôi) hơn là

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

nhưng tôi đoán nó đi xuống theo phong cách mã hóa

Không trả lời trực tiếp câu hỏi, nhưng dưới đây là một cú pháp ngắn về điều kiện nếu trên một dòng

Ví dụ:

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

Có thể được viết như thế này:

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

Có rất nhiều vấn đề trong javascript. Hãy nhìn vào kiến trúc sư Javascript Douglas Crockford nói về nó Các nếu tuyên bố có vẻ là tốt nhưng lại tuyên bố có thể giới thiệu một vấn đề.

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

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

Tôi tìm thấy câu trả lời này tìm kiếm về một trải nghiệm tương tự vì vậy tôi quyết định trả lời nó với kinh nghiệm của tôi.

Báo cáo không có khung làm việc trong hầu hết các trình duyệt, tuy nhiên, tôi đã thử nghiệm rằng các phương thức không có khung trong thực tế không hoạt động trong một số trình duyệt.

Kể từ ngày 26 tháng 2 năm 2018, tuyên bố này hoạt động trong Pale Moon, nhưng không phải Google Chrome.

function foo()
   return bar;

Mức thụt đầu dòng của một câu lệnh phải bằng với số dấu ngoặc mở phía trên nó. (không bao gồm dấu ngoặc kép được trích dẫn hoặc nhận xét hoặc chỉ định trong chỉ thị tiền xử lý)

Nếu không, K & R sẽ là phong cách thụt lề tốt. Để khắc phục kiểu của chúng, tôi khuyên bạn nên đặt các câu lệnh if đơn giản trên một dòng.

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

thay vì

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

Nếu tôi đang viết một trình soạn thảo, tôi sẽ làm cho nút định dạng tự động của nó hút thanh ngang hàng với foo và tôi sẽ làm cho nó chèn dấu ngoặc quanh thanh nếu bạn nhấn return trước khi nó như thế này:

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

Sau đó, thật dễ dàng và nhất quán để thêm các câu lệnh mới bên trên hoặc bên dưới thanh bên trong phần thân của câu lệnh if

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

Đôi khi chúng dường như là cần thiết! Tôi không thể tin vào bản thân mình, nhưng hôm qua nó đã xảy ra với tôi trong một phiên Firebird (Firefox 22.0 gần đây)

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

thực hiện làm một cái gì đó mặc dù my.condition.key là đúng . Thêm niềng răng:

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

Đã sửa vấn đề đó. Có rất nhiều ví dụ về việc nó dường như hoạt động mà không cần niềng răng, nhưng trong trường hợp này chắc chắn là không.

Tất nhiên, những người có xu hướng đặt nhiều hơn một tuyên bố trên một dòng nên chắc chắn luôn luôn sử dụng niềng răng, bởi vì những thứ như

if (condition)
    do something; do something else;

rất khó tìm.

Tôi chỉ muốn lưu ý rằng bạn cũng có thể loại bỏ các dấu ngoặc nhọn của người khác. Như đã thấy trong bài viết này của John Resig .

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

Có một cách để đạt được nhiều dòng niềng răng không cong nếu câu lệnh .. (Wow tiếng anh ..) nhưng thật là tẻ nhạt:

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


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