Mục đích của việc sử dụng dấu ngoặc nhọn (tức là {}) cho một dòng nếu hoặc vòng lặp là gì?

Tôi đang đọc một số ghi chú bài giảng của giảng viên C ++ của mình và ông đã viết như sau:

1. Sử dụng thụt lề // OK
2. Không bao giờ dựa vào quyền ưu tiên của nhà điều hành - Luôn sử dụng dấu ngoặc đơn // OK
3. Luôn sử dụng khối {} - ngay cả đối với một dòng // không ổn , tại sao ???
4. Đối tượng Const ở bên trái so sánh // OK
5. Sử dụng không dấu cho các biến là> = 0 // mẹo hay
6. Đặt Con trỏ thành NULL sau khi xóa - Bảo vệ xóa hai lần // không tệ

Kỹ thuật thứ 3 không rõ ràng với tôi: tôi sẽ đạt được gì khi đặt một dòng trong một { ... }?

Ví dụ: lấy mã kỳ lạ này:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

và thay thế nó bằng:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;

Lợi ích của việc sử dụng phiên bản 1 là gì?

Chúng ta cũng cố gắng sửa đổi ikhi chúng ta tăng j:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
        i++;

Ôi không! Đến từ Python, điều này có vẻ ổn, nhưng thực tế thì không, vì nó tương đương với:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Tất nhiên, đây là một sai lầm ngớ ngẩn, nhưng một lỗi mà ngay cả một lập trình viên có kinh nghiệm cũng có thể mắc phải.

Một lý do rất tốt khác được chỉ ra trong câu trả lời của ta.speot.is .

Một phần ba tôi có thể nghĩ là được lồng vào nhau if:

if (cond1)
   if (cond2) 
      doSomething();

Bây giờ, giả sử bây giờ bạn muốn doSomethingElse() khi cond1không được đáp ứng (tính năng mới). Vì thế:

if (cond1)
   if (cond2) 
      doSomething();
else
   doSomethingElse();

Điều này rõ ràng là sai, vì các elsecộng sự với bên trong if.

Chỉnh sửa: Vì điều này đang được chú ý, tôi sẽ làm rõ quan điểm của tôi. Câu hỏi tôi đã trả lời là:

Lợi ích của việc sử dụng phiên bản 1 là gì?

Mà tôi đã mô tả. Có một số lợi ích. Nhưng, IMO, quy tắc "luôn luôn" không luôn luôn được áp dụng. Vì vậy, tôi không hoàn toàn hỗ trợ

Luôn sử dụng khối {} - ngay cả đối với một dòng // không ổn, tại sao ???

Tôi không nói luôn luôn sử dụng một {}khối. Nếu đó là một điều kiện & hành vi đủ đơn giản, thì không. Nếu bạn nghi ngờ ai đó có thể đến sau & thay đổi mã của bạn để thêm chức năng, hãy làm.

Rất dễ dàng để vô tình thay đổi luồng điều khiển bằng các bình luận nếu bạn không sử dụng {và }. Ví dụ:

if (condition)
  do_something();
else
  do_something_else();

must_always_do_this();

Nếu bạn nhận xét do_something_else()bằng một nhận xét một dòng, bạn sẽ kết thúc với điều này:

if (condition)
  do_something();
else
  //do_something_else();

must_always_do_this();

Nó biên dịch, nhưng must_always_do_this()không phải lúc nào cũng được gọi.

Chúng tôi đã có vấn đề này trong cơ sở mã của chúng tôi, nơi ai đó đã vào để vô hiệu hóa một số chức năng rất nhanh trước khi phát hành. May mắn thay, chúng tôi đã bắt được nó trong đánh giá mã.

Tôi có nghi ngờ về năng lực của giảng viên. Xem xét điểm của mình:

1. đồng ý
2. Bất cứ ai sẽ thực sự viết (hoặc muốn đọc) (b*b) - ((4*a)*c)? Một số ưu tiên là rõ ràng (hoặc nên), và các dấu ngoặc đơn thêm chỉ gây thêm nhầm lẫn. (Mặt khác, bạn _should_ sử dụng dấu ngoặc đơn trong các trường hợp ít rõ ràng hơn, ngay cả khi bạn biết rằng chúng không cần thiết.)
3. Sắp xếp Có hai quy ước trải rộng để định dạng các điều kiện và vòng lặp:

   nếu (cond) {
       mã;
   }
   

   và:

   nếu (cond)
   {
       mã;
   }
   

   Đầu tiên, tôi đồng ý với anh ta. Phần mở đầu {không nhìn thấy được, vì vậy tốt nhất là giả sử nó luôn ở đó. Tuy nhiên, trong lần thứ hai, tôi (và hầu hết những người tôi đã làm việc cùng) không gặp vấn đề gì với việc bỏ niềng răng cho một tuyên bố duy nhất. (Tất nhiên, với điều kiện là sự thụt lề có hệ thống và bạn sử dụng phong cách này một cách nhất quán. (Và rất nhiều lập trình viên rất giỏi, viết mã rất dễ đọc, bỏ qua dấu ngoặc ngay cả khi định dạng theo cách đầu tiên.)
4. NO . Những thứ như if ( NULL == ptr )là đủ xấu để cản trở khả năng đọc. Viết các so sánh bằng trực giác. (Mà trong nhiều trường hợp dẫn đến hằng số ở bên phải.) 4 của anh ấy là lời khuyên tồi; bất cứ điều gì làm cho mã không tự nhiên làm cho nó ít đọc hơn.
5. NO . Bất cứ điều gì nhưng intđược dành riêng cho các trường hợp đặc biệt. Để lập trình viên C và C ++ có kinh nghiệm, việc sử dụng các unsignedtoán tử bit tín hiệu. C ++ không có loại hồng y thực sự (hoặc bất kỳ loại phân loại hiệu quả nào khác); unsignedkhông hoạt động cho các giá trị số, vì các quy tắc quảng cáo. Các giá trị số mà trên đó không có phép toán số học nào có ý nghĩa, như số sê-ri, có lẽ có thể là unsigned. Tuy nhiên, tôi tranh luận với nó bởi vì nó gửi thông điệp sai: các thao tác bitwise cũng không có ý nghĩa. Quy tắc cơ bản là các loại tích phân là int, _unless_ có một lý do quan trọng để sử dụng loại khác.
6. NO . Làm điều này một cách có hệ thống là sai lệch, và không thực sự bảo vệ chống lại bất cứ điều gì. Trong mã OO nghiêm ngặt, delete this;thường là trường hợp thường xuyên nhất (và bạn không thể đặt thisthành NULL), và nếu không, hầu hết deletelà trong các hàm hủy, vì vậy dù sao bạn cũng không thể truy cập con trỏ. Và thiết lập nó để NULLkhông làm bất cứ điều gì về bất kỳ con trỏ khác nổi xung quanh. Đặt con trỏ một cách có hệ thống để NULLmang lại cảm giác an toàn sai lầm và không thực sự mua cho bạn bất cứ thứ gì.

Nhìn vào mã trong bất kỳ tài liệu tham khảo điển hình. Ví dụ, Stroustrup vi phạm mọi quy tắc bạn đưa ra ngoại trừ quy tắc đầu tiên.

Tôi đề nghị bạn nên tìm một giảng viên khác. Một người thực sự biết những gì anh ấy đang nói về.

Tất cả các câu trả lời khác bảo vệ quy tắc 3 của giảng viên.

Hãy để tôi nói rằng tôi đồng ý với bạn: quy tắc là dư thừa và tôi sẽ không khuyên bạn. Đúng là về mặt lý thuyết, nó ngăn ngừa lỗi nếu bạn luôn thêm dấu ngoặc nhọn. Mặt khác, tôi chưa bao giờ gặp phải vấn đề này trong cuộc sống thực : trái với những gì câu trả lời khác ngụ ý, tôi đã không bao giờ quên thêm dấu ngoặc nhọn một khi chúng trở nên cần thiết. Nếu bạn sử dụng thụt lề thích hợp, điều rõ ràng là bạn cần thêm dấu ngoặc nhọn khi có nhiều hơn một câu lệnh được thụt lề.

Câu trả lời của Thành phần 10 10 thực sự làm nổi bật trường hợp duy nhất có thể hiểu được trong đó điều này thực sự có thể dẫn đến một lỗi. Nhưng mặt khác, việc thay thế mã thông qua biểu thức chính quy luôn luôn đảm bảo sự chăm sóc rất lớn.

Bây giờ chúng ta hãy nhìn vào mặt khác của huy chương: có bất lợi khi luôn luôn sử dụng dấu ngoặc nhọn không? Các câu trả lời khác chỉ đơn giản là bỏ qua điểm này. Nhưng có là một bất lợi: nó chiếm rất nhiều không gian màn hình thẳng đứng, và điều này đến lượt nó có thể làm cho mã của bạn không thể đọc được bởi vì nó có nghĩa là bạn phải di chuyển nhiều hơn mức cần thiết.

Hãy xem xét một hàm có nhiều mệnh đề bảo vệ ngay từ đầu (và vâng, sau đây là mã C ++ xấu nhưng trong các ngôn ngữ khác thì đây sẽ là một tình huống khá phổ biến):

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
    {
        throw null_ptr_error("a");
    }
    if (b == nullptr)
    {
        throw null_ptr_error("b");
    }
    if (a == b)
    {
        throw logic_error("Cannot do method on identical objects");
    }
    if (not a->precondition_met())
    {
        throw logic_error("Precondition for a not met");
    }

    a->do_something_with(b);
}

Đây là mã khủng khiếp và tôi lập luận mạnh mẽ rằng những điều sau đây dễ đọc hơn nhiều:

void some_method(obj* a, obj* b)
{
    if (a == nullptr)
        throw null_ptr_error("a");
    if (b == nullptr)
        throw null_ptr_error("b");
    if (a == b)
        throw logic_error("Cannot do method on identical objects");
    if (not a->precondition_met())
        throw logic_error("Precondition for a not met");

    a->do_something_with(b);
}

Tương tự, các vòng lặp lồng nhau ngắn có lợi khi bỏ qua các dấu ngoặc nhọn:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
        for (auto j = 0; j < a.h(); ++j)
            c(i, j) = a(i, j) + b(i, j);

    return c;
}

So sánh với:

matrix operator +(matrix const& a, matrix const& b) {
    matrix c(a.w(), a.h());

    for (auto i = 0; i < a.w(); ++i)
    {
        for (auto j = 0; j < a.h(); ++j)
        {
            c(i, j) = a(i, j) + b(i, j);
        }
    }

    return c;
}

Mã đầu tiên là súc tích; mã thứ hai bị cồng kềnh.

Và vâng, điều này có thể được giảm nhẹ đến một mức độ nào đó bằng cách đặt nẹp mở trên dòng trước đó. Nhưng điều đó vẫn sẽ sẽ dễ đọc hơn mã mà không có dấu ngoặc nhọn.

Tóm lại: không viết mã không cần thiết chiếm không gian màn hình.

Cơ sở mã hóa mà tôi đang làm việc bị phân tán bởi mã bởi những người có ác cảm bệnh lý với niềng răng, và đối với những người đi sau, nó thực sự có thể tạo ra sự khác biệt cho khả năng duy trì.

Ví dụ có vấn đề thường gặp nhất mà tôi gặp phải là:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
    this_looks_like_a_then-statement_but_isn't;

Vì vậy, khi tôi đi cùng và muốn thêm một tuyên bố sau đó, tôi có thể dễ dàng kết thúc với điều này nếu tôi không cẩn thận:

if ( really incredibly stupidly massively long statement that exceeds the width of the editor) do_foo;
{
    this_looks_like_a_then-statement_but_isn't;
    i_want_this_to_be_a_then-statement_but_it's_not;
}

Cho rằng phải mất ~ 1 giây để thêm niềng răng và có thể giúp bạn tiết kiệm tối thiểu một vài phút gỡ lỗi, tại sao bạn không bao giờ đi với tùy chọn giảm mơ hồ? Có vẻ như nền kinh tế sai lầm với tôi.

2c của tôi:

Sử dụng thụt lề

Chắc chắn

Không bao giờ dựa vào quyền ưu tiên của nhà điều hành - Luôn sử dụng dấu ngoặc đơn

Tôi sẽ không sử dụng các từ "không bao giờ và" luôn luôn ", nhưng nói chung tôi thấy quy tắc này hữu ích. Trong một số ngôn ngữ (Lisp, Smalltalk) đây không phải là vấn đề.

Luôn sử dụng khối {} - ngay cả đối với một dòng

Tôi không bao giờ làm điều đó và không bao giờ có một vấn đề duy nhất, nhưng tôi có thể thấy làm thế nào nó có thể tốt cho sinh viên, đặc biệt. nếu họ học Python trước.

Đối tượng Const ở bên trái so sánh

Điều kiện Yoda? Không, làm ơn. Nó làm tổn thương khả năng đọc. Chỉ cần sử dụng mức cảnh báo tối đa khi bạn biên dịch mã của mình.

Sử dụng không dấu cho các biến> = 0

ĐỒNG Ý. Buồn cười quá, tôi đã nghe Stroustrup không đồng ý.

Đặt Con trỏ thành NULL sau khi xóa - Bảo vệ xóa hai lần

Lời khuyên tệ! Không bao giờ có một con trỏ trỏ đến một đối tượng bị xóa hoặc không tồn tại.

nó trực quan hơn và dễ hiểu Nó làm cho ý định rõ ràng.

Và nó đảm bảo rằng mã không bị hỏng khi người dùng mới có thể vô tình bỏ lỡ {, }trong khi thêm một tuyên bố mã mới.

Để thêm vào các đề xuất rất hợp lý ở trên, một ví dụ tôi gặp phải khi tái cấu trúc một số mã trong đó điều này trở nên quan trọng như sau: Tôi đã thay đổi một cơ sở mã rất lớn để chuyển từ API này sang API khác. API đầu tiên có lệnh gọi để đặt Id công ty như sau:

setCompIds( const std::string& compId, const std::string& compSubId );

trong khi đó sự thay thế cần hai cuộc gọi:

setCompId( const std::string& compId );
setCompSubId( const std::string& compSubId );

Tôi bắt đầu thay đổi điều này bằng cách sử dụng các biểu thức chính quy rất thành công. Chúng tôi cũng đã chuyển mã thông qua astyle , điều này thực sự làm cho nó dễ đọc hơn rất nhiều. Sau đó, một phần trong quá trình xem xét, tôi phát hiện ra rằng trong một số trường hợp có điều kiện, nó đã thay đổi điều này:

if ( condition )
   setCompIds( compId, compSubId );

Về điều này:

if ( condition )
   setCompId( compId );
setCompSubId( compSubId );

đó rõ ràng không phải là những gì được yêu cầu. Tôi đã phải quay lại từ đầu để làm điều này một lần nữa bằng cách coi việc thay thế hoàn toàn trong một khối và sau đó thay đổi thủ công bất cứ thứ gì cuối cùng trông có vẻ ngớ ngẩn (ít nhất là nó sẽ không chính xác.)

Tôi nhận thấy rằng astyle hiện có tùy chọn --add-bracketscho phép bạn thêm dấu ngoặc ở những nơi không có và tôi thực sự khuyên bạn nên làm điều này nếu bạn thấy mình ở vị trí giống như tôi.

Tôi đang sử dụng {}ở mọi nơi ngoại trừ một vài trường hợp rõ ràng. Dòng đơn là một trong những trường hợp:

if(condition) return; // OK

if(condition) // 
   return;    // and this is not a one-liner 

Nó có thể làm tổn thương bạn khi bạn thêm một số phương pháp trước khi trở lại. Sự thụt lề chỉ ra rằng trả về là thực thi khi điều kiện được đáp ứng, nhưng nó sẽ luôn luôn trở lại.

Ví dụ khác trong C # với việc sử dụng statment

using (D d = new D())  // OK
using (C c = new C(d))
{
    c.UseLimitedResource();
}

tương đương với

using (D d = new D())
{
    using (C c = new C(d))
    {
        c.UseLimitedResource();
    }
}

Ví dụ thích hợp nhất tôi có thể nghĩ ra:

if(someCondition)
   if(someOtherCondition)
      DoSomething();
else
   DoSomethingElse();

Mà ifsẽ elseđược kết hợp với? Sự thụt lề ngụ ý rằng bên ngoài ifcó được else, nhưng đó không thực sự là cách trình biên dịch sẽ nhìn thấy nó; các bên if sẽ nhận được else, và bên ngoài ifthì không. Bạn sẽ phải biết rằng (hoặc thấy nó hoạt động theo cách đó trong chế độ gỡ lỗi) để tìm ra bằng cách kiểm tra lý do tại sao mã này có thể không đáp ứng mong đợi của bạn. Sẽ khó hiểu hơn nếu bạn biết Python; trong trường hợp đó bạn biết rằng thụt đầu dòng xác định các khối mã, vì vậy bạn sẽ mong đợi nó đánh giá theo cách thụt lề. C #, tuy nhiên, không đưa ra một cú lật về khoảng trắng.

Bây giờ, điều đó nói rằng, tôi không đặc biệt đồng ý với quy tắc "luôn luôn sử dụng dấu ngoặc" này trên mặt của nó. Nó làm cho mã rất ồn theo chiều dọc, làm giảm khả năng đọc qua nó một cách nhanh chóng. Nếu tuyên bố là:

if(someCondition)
   DoSomething();

... Sau đó nó nên được viết như thế này. Câu lệnh "luôn luôn sử dụng dấu ngoặc" nghe giống như "luôn bao quanh các phép toán với dấu ngoặc đơn". Điều đó sẽ biến tuyên bố rất đơn giản a * b + c / dthành ((a * b) + (c / d)), giới thiệu khả năng thiếu một paren gần (nguyên nhân của nhiều lập trình viên), và để làm gì? Thứ tự của các hoạt động là nổi tiếng và được thực thi tốt, vì vậy các dấu ngoặc là dư thừa. Bạn chỉ sử dụng dấu ngoặc đơn để thực thi một thứ tự hoạt động khác so với thông thường sẽ được áp dụng: a * (b+c) / dví dụ: Niềng răng khối cũng tương tự; sử dụng chúng để xác định những gì bạn muốn làm trong trường hợp nó khác với mặc định và không "rõ ràng" (chủ quan, nhưng thường khá thông thường).

Nhìn qua các câu trả lời, không ai nói rõ loại thực hành mà tôi tạo thói quen, kể câu chuyện về mã của bạn:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

Trở thành:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0) j++;
}

Đưa j++trên cùng một dòng như nếu nên báo hiệu cho bất cứ ai khác, "Tôi chỉ muốn khối này để tăng bao giờ j" . Của coursethis chỉ có giá trị nếu dòng càng đơn giản càng tốt, bởi vì đặt một điểm dừng ở đây, như peri đề cập, sẽ không hữu ích lắm.

Trong thực tế, tôi vừa chạy qua một phần API Storm của Twitter có 'loại' mã này trong java, đây là đoạn mã phụ thuộc dạng mã thực thi, trên trang 43 của trình chiếu này :

...
Integer Count = counts.get(word);
if (Count=null) count=0;
count++
...

Khối vòng lặp for có hai thứ trong đó, vì vậy tôi sẽ không nội tuyến mã đó. Tức là không bao giờ :

int j = 0;
for (int i = 0 ; i < 100 ; ++i) if (i % 2 == 0) j++;

Thật tồi tệ và tôi thậm chí không biết nếu nó hoạt động (như dự định); không làm điều này . Các dòng và dấu ngoặc mới giúp phân biệt các đoạn mã riêng biệt nhưng có liên quan, giống như cách một dấu phẩy hoặc dấu chấm phẩy thực hiện trong văn xuôi. Khối trên xấu như một câu thực sự dài với một vài mệnh đề và một số câu khác không bao giờ ngắt hoặc tạm dừng để phân biệt các phần riêng biệt.

Nếu bạn thực sự muốn điện báo cho người khác, đó là công việc một dòng chỉ sử dụng toán tử hoặc ?:biểu mẫu ba:

for (int i = 0 ; i < 100 ; ++i) (i%2 ? 0 : >0) j++;

Nhưng điều này đang tràn ngập trong môn đánh gôn, và tôi nghĩ không phải là môn tập luyện tuyệt vời (Tôi không rõ liệu tôi có nên đặt j ++ ở một bên :hay không). NB Tôi chưa từng chạy toán tử ternary trong C ++ trước đây, tôi không biết điều này có hoạt động không, nhưng nó có tồn tại không .

Nói ngắn gọn:

Hãy tưởng tượng cách người đọc của bạn (tức là người duy trì mã) diễn giải câu chuyện của bạn (mã). Làm cho nó rõ ràng cho họ càng tốt. Nếu bạn biết lập trình viên / sinh viên mới làm quen đang duy trì điều này, thậm chí có thể để lại càng nhiều {}càng tốt, để họ không bị nhầm lẫn.

Bởi vì khi bạn có hai tuyên bố mà không có {}, rất dễ bỏ lỡ một vấn đề. Hãy giả sử rằng mã trông như thế này.

int error = 0;
enum hash_type hash = SHA256;
struct hash_value *hash_result = hash_allocate();

if ((err = prepare_hash(hash, &hash_result))) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &client_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &server_random)) != 0)
    goto fail;
if ((err = hash_update(&hash_result, &exchange_params)) != 0)
    goto fail;
    goto fail;
if ((err = hash_finish(hash)) != 0)
    goto fail;

error = do_important_stuff_with(hash);

fail:
hash_free(hash);
return error;

Nó trông ổn đấy. Vấn đề với nó thực sự rất dễ bỏ lỡ, đặc biệt là khi hàm chứa mã lớn hơn nhiều. Vấn đề goto faillà chạy vô điều kiện. Bạn có thể dễ dàng tưởng tượng điều này gây khó chịu như thế nào (khiến bạn hỏi tại sao cuối cùng hash_updateluôn thất bại, sau khi tất cả mọi thứ có vẻ tốt trong hash_updatechức năng).

Tuy nhiên, điều đó không có nghĩa là tôi thêm vào {}mọi nơi (theo tôi, nhìn thấy {}mọi nơi đều gây phiền nhiễu). Mặc dù nó có thể gây ra sự cố, nhưng nó không bao giờ làm cho các dự án của riêng tôi, vì phong cách mã hóa cá nhân của tôi cấm các điều kiện mà không có {}khi chúng không cùng dòng (vâng, tôi đồng ý rằng phong cách mã hóa của tôi là độc đáo, nhưng tôi thích nó, và tôi sử dụng kiểu mã của dự án khi đóng góp cho các dự án khác). Điều này làm cho mã sau đây tốt.

if (something) goto fail;

Nhưng không phải cái sau.

if (something)
    goto fail;

Nó làm cho mã của bạn dễ đọc hơn bằng cách xác định rõ phạm vi của các vòng lặp và các khối có điều kiện. Nó cũng cứu bạn khỏi những sai lầm tình cờ.

wrt 6: An toàn hơn vì xóa một con trỏ null là không có. Vì vậy, nếu bạn vô tình đi qua con đường đó hai lần, bạn sẽ không làm hỏng bộ nhớ để giải phóng bộ nhớ miễn phí hoặc đã được phân bổ cho thứ khác.

Đây là hầu hết các vấn đề với các đối tượng và singletons phạm vi tệp tĩnh không có thời gian sống rất rõ ràng và được biết là được tạo lại sau khi chúng bị phá hủy.

Trong hầu hết các trường hợp, bạn có thể tránh sự cần thiết này bằng cách sử dụng auto_ptrs

Tôi thích câu trả lời được chấp nhận của Luchian, trên thực tế tôi đã học được một cách khó khăn rằng anh ấy đúng, vì vậy tôi luôn sử dụng niềng răng, ngay cả đối với các khối đơn. Tuy nhiên, cá nhân tôi tạo một ngoại lệ khi viết bộ lọc, như bạn đang ở trong ví dụ của bạn. Điều này:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}

có vẻ lộn xộn với tôi. Nó tách vòng lặp for và câu lệnh if thành các hành động riêng biệt, khi thực sự ý định của bạn là một hành động duy nhất: đếm tất cả các số nguyên chia hết cho 2. Trong một ngôn ngữ biểu cảm hơn, điều này có thể được viết như sau:

j = [1..100].filter(_%2 == 0).Count

Trong các ngôn ngữ thiếu các bao đóng, bộ lọc không thể được biểu thị trong một câu lệnh đơn lẻ, nhưng phải là một vòng lặp for theo sau là một câu lệnh if. Tuy nhiên, đó vẫn là một hành động trong tâm trí của lập trình viên và tôi tin rằng điều đó nên được phản ánh trong mã, như vậy:

int j = 0;
for (int i = 0 ; i < 100 ; ++i)
  if (i % 2 == 0)
{
    j++;
}

Một tùy chọn để giúp ngăn ngừa các lỗi đã được mô tả ở trên là nội tuyến những gì bạn muốn xảy ra khi bạn không sử dụng niềng răng. Nó làm cho khó khăn hơn nhiều để không nhận thấy các lỗi khi bạn cố gắng sửa đổi mã.

if (condition) doSomething();
else doSomethingElse();

if (condition) doSomething();
    doSomething2(); // Looks pretty obviously wrong
else // doSomethingElse(); also looks pretty obviously wrong

Nếu bạn là một trình biên dịch, nó sẽ không tạo ra bất kỳ sự khác biệt nào. Cả hai đều giống nhau.

Nhưng đối với các lập trình viên, cái đầu tiên rõ ràng hơn, dễ đọc và ít bị lỗi hơn.

Một ví dụ khác về việc thêm dấu ngoặc nhọn. Khi tôi đang tìm kiếm một lỗi và tìm thấy mã như vậy:

void SomeSimpleEventHandler()
{
    SomeStatementAtTheBeginningNumber1;
    if (conditionX) SomeRegularStatement;
    SomeStatementAtTheBeginningNumber2;
    SomeStatementAtTheBeginningNumber3;
    if (!SomeConditionIsMet()) return;
    OtherwiseSomeAdditionalStatement1;
    OtherwiseSomeAdditionalStatement2;
    OtherwiseSomeAdditionalStatement3;
}

Nếu bạn đọc từng phương thức theo từng dòng, bạn sẽ nhận thấy rằng có một điều kiện trong phương thức trả về nếu nó không đúng. Nhưng thực tế có vẻ như 100 trình xử lý sự kiện đơn giản khác đặt một số biến dựa trên một số điều kiện. Và một ngày, Bộ giải mã nhanh xuất hiện và thêm câu lệnh thiết lập biến bổ sung vào cuối phương thức:

{
    ...
    OtherwiseSomeAdditionalStatement3;
    SetAnotherVariableUnconditionnaly;
}

Kết quả là SetAnotherVariableUnconditionnaly được thực thi khi someConditionIsMet (), nhưng anh chàng nhanh chóng không chú ý đến nó bởi vì tất cả các dòng có kích thước gần như tương tự và ngay cả khi điều kiện quay trở lại được thụt theo chiều dọc, nó không đáng chú ý.

Nếu lợi nhuận có điều kiện được định dạng như thế này:

if (!SomeConditionIsMet())
{
    return;
}

nó rất đáng chú ý và Fast Coder sẽ tìm thấy nó trong nháy mắt.

Tôi xem xét cái đầu tiên là rõ ràng sau đó thứ hai. Nó mang lại cảm giác đóng hướng dẫn, với ít mã là tốt khi mã trở nên phức tạp {...}giúp ích rất nhiều ngay cả khi nó là endifhoặcbegin...end

//first
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
{
    if (i % 2 == 0)
    {
        j++;
    }
}


//second
int j = 0;
for (int i = 0 ; i < 100 ; ++i)
    if (i % 2 == 0)
        j++;
i++;

Tốt nhất là đặt con trỏ thành NULL khi bạn đã hoàn thành với nó.

Đây là một ví dụ tại sao:

Lớp A thực hiện như sau:

1. Phân bổ một khối bộ nhớ
2. Sau đó một thời gian, nó xóa khối bộ nhớ này nhưng không đặt con trỏ thành NULL

Lớp B làm như sau

1. Phân bổ bộ nhớ (và trong trường hợp này, nó tình cờ được cung cấp cùng một khối bộ nhớ đã bị xóa bởi lớp A.)

Tại thời điểm này, cả Lớp A và Lớp B đều có con trỏ trỏ đến cùng một khối bộ nhớ, theo như Lớp A có liên quan thì khối bộ nhớ này không tồn tại vì nó đã kết thúc với nó.

Hãy xem xét vấn đề sau:

Điều gì xảy ra nếu có lỗi logic trong Lớp A dẫn đến việc nó ghi vào bộ nhớ mà bây giờ thuộc về Lớp B?

Trong trường hợp cụ thể này, bạn sẽ không gặp phải lỗi ngoại lệ truy cập xấu vì địa chỉ bộ nhớ là hợp pháp, tất cả các lớp A hiện đang làm hỏng dữ liệu lớp B một cách hiệu quả.

Lớp B cuối cùng có thể gặp sự cố nếu gặp phải các giá trị không mong muốn và khi nó gặp sự cố, rất có thể, bạn sẽ mất khá nhiều thời gian để săn lỗi này trong lớp B khi sự cố thuộc lớp A.

Nếu bạn đã đặt con trỏ bộ nhớ đã xóa thành NULL, bạn sẽ gặp lỗi ngoại lệ ngay khi có bất kỳ lỗi logic nào trong Lớp A cố ghi vào con trỏ NULL.

Nếu bạn lo lắng về lỗi logic khi xóa hai lần khi con trỏ là NULL lần thứ hai, thì hãy thêm xác nhận cho việc này.

Ngoài ra: Nếu bạn sẽ bỏ phiếu, xin vui lòng giải thích.

Luôn luôn có niềng răng là quy tắc rất đơn giản và mạnh mẽ. Tuy nhiên, mã có thể trông không phù hợp khi có nhiều dấu ngoặc nhọn. Nếu các quy tắc cho phép bỏ qua các dấu ngoặc nhọn thì nên có các quy tắc kiểu chi tiết hơn và các công cụ tinh vi hơn. Nếu không, nó có thể dễ dàng dẫn đến mã hỗn loạn và khó hiểu (không thanh lịch). Do đó, tìm kiếm quy tắc kiểu đơn tách biệt với phần còn lại của hướng dẫn kiểu và công cụ được sử dụng có thể không có kết quả. Tôi sẽ chỉ đưa ra một số chi tiết quan trọng về quy tắc số 3 mà thậm chí chưa được đề cập trong các câu trả lời khác.

Chi tiết thú vị đầu tiên là hầu hết những người đề xuất quy tắc đó đồng ý vi phạm nó trong trường hợp else. Nói cách khác, họ không yêu cầu xem lại mã như vậy:

// pedantic rule #3
if ( command == Eat )
{
    eat();
}
else
{
    if ( command == Sleep )
    {
        sleep();
    }
    else
    {
        if ( command == Drink )
        {
            drink();
        }
        else
        {
            complain_about_unknown_command();
        }
    }
}

Thay vào đó, nếu họ thấy nó, họ thậm chí có thể đề nghị viết nó như thế:

// not fully conforming to rule #3
if ( command == Eat )
{
    eat();
}
else if ( command == Sleep )
{
    sleep();
}
else if ( command == Drink )
{
    drink();
}
else
{
   complain_about_unknown_command();
}

Đó là vi phạm kỹ thuật của quy tắc đó vì không có dấu ngoặc nhọn giữa elsevà if. Tính hai mặt như vậy xuất hiện khi cố gắng áp dụng nó vào cơ sở mã tự động với một công cụ không cần suy nghĩ. Thật vậy, tại sao để tranh luận, chỉ cần để một công cụ để áp dụng phong cách tự động.

Chi tiết thứ hai (cũng thường bị quên bởi những người đề xuất quy tắc đó) là các lỗi có thể xảy ra không bao giờ chỉ vì vi phạm quy tắc số 3 đó. Trên thực tế những điều đó hầu như luôn liên quan đến việc vi phạm quy tắc số 1 quá (mà không ai tranh cãi). Một lần nữa theo quan điểm của các công cụ tự động, không khó để tạo ra một công cụ phàn nàn ngay lập tức khi quy tắc số 1 bị vi phạm và vì vậy hầu hết các lỗi có thể được phát hiện kịp thời.

Chi tiết thứ ba (thường bị các đối thủ của quy tắc đó lãng quên) là bản chất khó hiểu của tuyên bố trống rỗng được thể hiện bằng dấu chấm phẩy đơn. Hầu hết các nhà phát triển với một số kinh nghiệm đã sớm bị nhầm lẫn bởi dấu chấm phẩy không đúng chỗ hoặc bởi câu lệnh trống được viết bằng dấu chấm phẩy duy nhất. Hai dấu ngoặc nhọn thay vì dấu chấm phẩy đơn dễ nhìn thấy hơn.

Tôi phải thừa nhận rằng không phải lúc nào cũng sử dụng {}cho một dòng, nhưng đó là một thực hành tốt.

• Hãy nói rằng bạn viết một mã không có dấu ngoặc giống như thế này:

  for (int i = 0; i <100; ++ i) for (int j = 0; j <100; ++ j) DoSingleStuff ();

Và sau một thời gian bạn muốn thêm vào jvòng lặp một số thứ khác và bạn chỉ cần làm điều đó bằng cách căn chỉnh và quên thêm dấu ngoặc.

• Giải quyết bộ nhớ nhanh hơn. Hãy nói rằng bạn có phạm vi lớn và tạo các mảng lớn bên trong (không có newchúng trong ngăn xếp). Những mảng đó sẽ bị xóa khỏi bộ nhớ ngay sau khi bạn rời khỏi phạm vi. Nhưng có thể bạn sử dụng mảng đó ở một nơi và nó sẽ được xếp chồng lên nhau trong một thời gian và là một loại rác. Vì một ngăn xếp có kích thước hạn chế và khá nhỏ, có thể vượt quá kích thước ngăn xếp. Vì vậy, trong một số trường hợp tốt hơn là viết {}để ngăn chặn điều đó. LƯU Ý đây không phải cho một dòng mà cho các tình huống như vậy:

  if (...) {// someStuff ... {// chúng tôi không có if, while, v.v. // someOtherStuff} // someMoreStuff}

• Cách thứ ba để sử dụng nó tương tự với thứ hai. Nó không chỉ để làm cho stack sạch hơn mà để mở một số chức năng. Nếu bạn sử dụng mutextrong các chức năng dài thường thì tốt hơn là khóa và mở khóa ngay trước khi truy cập dữ liệu và ngay sau khi đọc xong / ghi nó. LƯU Ý cách này được sử dụng nếu bạn có một số của riêng bạn classhoặc structcó constructorvà destructorđể khóa bộ nhớ.

• Hơn thế nữa:

  if (...) if (...) someStuff (); other someOtherStuff (); // đi đến lần thứ hai nếu, nhưng phân bổ cho thấy nó ở trên ...

Tất cả trong tất cả, tôi không thể nói, cách tốt nhất để luôn luôn sử dụng {}cho một dòng duy nhất nhưng không có gì xấu khi làm điều đó.

EDIT QUAN TRỌNG Nếu bạn viết biên dịch mã biên dịch cho một dòng duy nhất thì không có gì, nhưng nếu mã của bạn sẽ bị hiểu thì nó làm chậm mã rất ít. Rất nhẹ.

Có một số cách có thể để viết các tuyên bố kiểm soát; một số kết hợp nhất định có thể cùng tồn tại mà không làm giảm mức độ dễ đọc, nhưng các kết hợp khác sẽ gây rắc rối. Phong cách

if (condition)
  statement;

sẽ cùng tồn tại thoải mái với một số cách viết câu kiểm soát khác, nhưng không tốt với những cách khác. Nếu báo cáo kiểm soát nhiều dòng được viết là:

if (condition)
{
  statement;
  statement;
}

sau đó sẽ hiển thị rõ ràng ifcâu lệnh nào điều khiển một dòng đơn và câu lệnh nào điều khiển nhiều dòng. Tuy nhiên, nếu các ifcâu lệnh nhiều dòng được viết là:

if (condition) {
  statement;
  statement;
}

thì khả năng ai đó cố gắng mở rộng cấu trúc một câu lệnh ifmà không thêm các dấu ngoặc cần thiết có thể cao hơn nhiều.

Câu lệnh một câu lệnh tiếp theo ifcũng có thể có vấn đề nếu cơ sở mã sử dụng biểu mẫu

if (condition) statement;

Sở thích riêng của tôi là có câu lệnh trên dòng riêng của mình nói chung giúp tăng cường mức độ dễ đọc trừ trường hợp có nhiều ifcâu lệnh có khối điều khiển tương tự, ví dụ:

if (x1 > xmax) x1 = xmax;
if (x1 < xmin) x1 = xmin;
if (x2 > xmax) x2 = xmax;
if (x2 < xmin) x2 = xmin;
etc.

trong trường hợp đó, tôi thường sẽ đi trước và theo dõi các nhóm ifcâu lệnh như vậy với một dòng trống để tách chúng ra khỏi mã khác một cách trực quan. Có một loạt các câu lệnh mà tất cả bắt đầu bằng ifcùng một vết lõm sẽ cung cấp một dấu hiệu trực quan rõ ràng rằng có điều gì đó bất thường.