2009-03-27 42 views
17
if (condition) { /* do something */ } 
else { /* do something */ } 

if (condition) 
    /* do something */ 
else 
    /* do something */ 

Tôi được thông báo rằng trường hợp đầu tiên không phải là một ý tưởng hay. Tôi không biết liệu đây có phải là trường hợp này hay không (hoặc trường hợp thứ hai); nó không rút ngắn số lượng cần nhập? Hay là vì nó chỉ gây ra một mớ hỗn độn?Có phải là câu hỏi đơn nếu câu lệnh hoặc câu lệnh không có dấu ngoặc kép không?

Trả lời

33

Cách tốt nhất là để viết mã mà những người khác có thể đọc và cập nhật một cách dễ dàng.

hình thức đầu tiên của bạn là đáng ngờ vì nó không làm theo các hình thức mà hầu hết các nhà phát triển PHP được sử dụng để:

if (condition) { 
    // code 
} else { 
    // code 
} 

// ... or ... 

if (condition) 
{ 
    // code 
} 
else 
{ 
    // code 
} 

// ... or ... 

if (condition) { /* short code */ } else { /* short code */ } 

// ... or ... 

condition ? /* short code */ : /* short code */; 

Lưu ý rằng điều này là hoàn toàn về thực hành tiêu chuẩn, và không nhất thiết có ý nghĩa — nó chỉ về những gì các nhà phát triển khác được sử dụng để xem.

hình thức thứ hai của bạn, quan trọng hơn, không phải là quá tốt vì nó làm cho nó dễ dàng cho lập trình viên khác để làm cho sai lầm này:

if (condition) 
    // code A 
else 
    // code B 
    // code C (added by another programmer) 

Trong ví dụ này, các lập trình viên khác bổ sung code C, nhưng quên quấn toàn bộ khối else trong niềng răng. Điều này sẽ gây ra vấn đề. Bạn có thể bảo vệ chống lại điều này bằng cách chỉ cần gói các khối ifelse của bạn trong niềng răng.

+0

Thực ra, tôi đã từng có niềng răng trên các dòng riêng biệt. – unrelativity

+0

Đây là phương pháp hay nhất thứ 2 - tốt nhất là viết theo cùng một kiểu với tác giả gốc - mặc dù tôi cho rằng điều này cũng đúng :) – Brian

+4

Tôi không đồng ý với điểm số 2. Chỉ có một lập trình viên thực sự khủng khiếp sẽ làm điều gì đó giống như thêm mã C mà không cần niềng răng. – rlbond

5

Nói chung mã không thể đọc là một thực tiễn không tốt. Các dòng đơn là hiệu quả hơn trong đánh máy của bạn và tiết kiệm số dòng nhưng trở lại với nó một năm kể từ bây giờ hoặc trong khi bạn đang quét lỗi và nó sẽ làm cho nó khó khăn hơn.

Theo ý kiến ​​của tôi, có thực tế không tốt nếu có dòng đơn nếu câu lệnh.

Máy tính không thực sự quan tâm (theo như tôi có thể nói) nhưng bạn nên luôn viết mã của bạn giống như nó sẽ được duy trì bởi một kẻ giết người hàng loạt biết bạn sống ở đâu.

Có thể đọc được! Dễ dàng tự nhận ra.

+0

@jerebear này trông giống như một bình luận hơn là một câu trả lời :) – eglasius

+0

Có lẽ tôi không đủ cụ thể, tôi sẽ chỉnh sửa. – jerebear

4

Vấn đề tôi đã thấy là các nhà phát triển không nhận ra {} -less-if khi họ thêm mã vào một trong các điều kiện. Ví dụ:

//before 
if(something) 
    statement; 

//after 
if(something) 
    statement; 
    addedstatement; 

Rõ ràng, điều này sẽ không làm những gì họ mong đợi.

+1

Tôi thuộc tính này cho họ không hiểu ngôn ngữ. Tôi thường không cố chỉnh sửa mã của mình cho những người không biết ngôn ngữ tôi đang viết. Điều đó nói rằng, nếu trong một hoàn cảnh cụ thể nó trở nên ít có thể đọc được, những người là chuyên gia vẫn có thể gặp khó khăn. –

0

Đó là hai dòng dài, do đó, không thực sự là một dòng.

Không có gì sai với một dòng if s khi nó làm cho mã dễ dàng hơn để đọc.

Ví dụ, một cái gì đó như thế này:

if (last_item) print ", and " else print ", " 

là tốt hơn nhiều so với

if (last_iem) 
{ 
    print ", and " 
} 
else 
{ 
    print ", " 
} 
+2

Cả hai đều xấu. Điều tốt nhất là 'echo (last_item)? ", và": ","; '. Và cố gắng sử dụng echo, nhân tiện. –

8

Tùy chọn của tôi nếu nhất quán ...vậy:

if(...) 
{ 
    statement 1; 
    statement 2; 
} 
else 
{ 
    statement 1; 
    statement 2; 
} 

là không khác gì hơn:

if(...) 
{ 
    statement 1; 
} 
else 
{ 
    statement 1; 
} 

Vì vậy, tôi luôn luôn sử dụng chúng bởi vì nó là phù hợp và nó tránh được các vấn đề quên để thêm chúng vào sau đó.

Tuy nhiên, những người khác sẽ xem mã của tôi và nghĩ rằng thật ngu ngốc khi đặt trong {và}. Họ có lý do của họ, tôi có của tôi ... Tôi xảy ra như lý do của tôi nhiều hơn tôi thích của họ :-)

+0

Chúc mừng :) Tôi làm như vậy, và vì lý do tương tự: không quên thêm dấu ngoặc nhọn sau. Tôi cũng yêu {trên dòng mới hơn là nếu (contidion) {vì nó không phải lúc nào cũng nhìn thấy được. –

0

Đây là phong cách mã hóa hơn bất cứ điều gì khác. Điều đó nói rằng, ý kiến ​​cá nhân của tôi là ví dụ thứ hai của bạn có tiềm năng khá nguy hiểm. Thật dễ dàng để vô tình "thêm một dòng thứ hai vào khối" trong ngôn ngữ mà niềng răng là cách duy nhất để tạo khối. Nhưng trong PHP, khi một cú pháp thay thế tồn tại, điều này thậm chí còn ít có khả năng xảy ra các chuông cảnh báo cần thiết:

Quy tắc: nếu bạn định đặt "làm điều gì đó" trên một dòng riêng biệt , sử dụng niềng răng; nếu bạn không sử dụng niềng răng, hãy đặt nó trên cùng một dòng!

1

Đối với tất cả trừ các câu lệnh ngắn nhất, hãy sử dụng niềng răng và cách khoảng trống cho phù hợp. Bạn muốn thực hiện việc này vì một vài lý do:

  • Thật khó để nhầm lẫn về nơi xảy ra sự cố.

  • Dễ đọc hơn.

  • Ở các ngôn ngữ có tiện ích mở rộng macro (ví dụ: C, C++), không bao gồm dấu ngoặc sẽ gây ra lỗi logic khó hiểu khi macro chứa nhiều câu lệnh được mở rộng bên trong một số không được đính kèm if-else.

0

Tôi đã thấy rất nhiều mã của bên thứ ba với các vấn đề ngớ ngẩn, rằng tôi thích sử dụng niềng răng mọi lúc. Điều đó nói rằng tôi chưa bao giờ cảm thấy tốt trên

if(){} 
else(){} 

Tôi sử dụng if() {} trên cùng một dòng khi nó là một hướng dẫn ngắn và chỉ có một mình. Nếu có người khác sử dụng lâu:

if(checkSomething) 
{ 
    //dosomething 
} 
else 
{ 
    //doanotherthing 
} 
0

Đây là điều tôi thực sự nhớ từ một kỳ thi tuyển dụng một thời gian trở lại. Mã này tương tự như sau:

if (x == 0) 
    x = 2; 
else 
    print("x is: %d", x); // debugging! 
    x = 4; 

Hầu hết mọi người ở đây đều có thể phát hiện lỗi, nhưng bạn có thể thay thế bất kỳ thứ gì bạn muốn làm "mã xấu" được chèn. Các lỗi tinh tế hơn đến khi bạn có một "phiên bản cũ" của một cái gì đó nhận xét ra, và ai đó un-nhận xét nó, và đột nhiên tuyên bố thứ hai là bên ngoài khối. Về cơ bản, trừ khi nó là một ứng dụng thử nghiệm nhỏ để tìm hiểu một khái niệm nhanh chóng, tôi luôn luôn khung (và ngay cả trong các ứng dụng thử nghiệm I thường là khung). Nó chỉ là không có giá trị đau đầu sau này nếu tôi không, ngay cả trong 5-line-phương pháp.

3

Bạn đã bao giờ thấy mã như thế này trong C hoặc C++ chưa?

/* Warning: bogus C code! */ 

if (some condition) 
     if (another condition) 
       do_something(fancy); 
else 
     this_sucks(badluck); 

Hoặc thụt lề là sai, hoặc chương trình bị lỗi vì "khác" luôn áp dụng cho "if" gần nhất, trừ khi bạn sử dụng niềng răng.

(Hãy chỉ sử dụng python Không dấu ngoặc, chỉ cần tinh khiết khoảng trắng sạch:.. P)

1

Một lợi ích lớn của việc sử dụng nhiều dòng là dễ gỡ lỗi. Nếu bạn có một câu lệnh if else trên cùng một dòng và trình gỡ lỗi cho bạn biết rằng dòng x đã bị phá vỡ, sẽ khó xác định phần nào của câu lệnh bị lỗi. Nhiều dòng cũng giúp bạn dễ dàng duyệt qua mã của mình bằng trình gỡ lỗi.

0

Bạn nên đặt "if" và "làm điều gì đó" trên các dòng riêng biệt để làm cho mã của bạn thân thiện hơn với các trình gỡ rối tương tác.

Nếu bạn đặt cả hai "nếu" và "làm điều gì đó" trên cùng một dòng, thì bạn không thể đặt điểm ngắt chỉ trên dòng "làm điều gì đó".

Các vấn đề liên quan