Niềng răng xoăn nên xuất hiện trên dòng riêng của họ? [đóng cửa]

Có nên niềng răng xoăn trên đường dây của mình hay không? Bạn nghĩ gì về nó?

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

hoặc nó nên

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

hoặc thậm chí

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

Hãy xây dựng! Giải thích tại sao, chia sẻ kinh nghiệm, sao lưu nó với các sự kiện và tài liệu tham khảo.

Khi còn là sinh viên, tôi thường đặt các dấu ngoặc nhọn trên cùng một dòng, để có ít dòng hơn và mã được in trên ít trang hơn. Nhìn vào một ký tự dấu ngoặc đơn được in là điều duy nhất trong một dòng là khó chịu. (môi trường, lãng phí giấy)

Nhưng khi mã hóa các ứng dụng lớn, cho phép một số dòng chỉ có niềng răng trong đó có giá cả phải chăng, xem xét cảm giác 'nhóm' mà nó mang lại.

Cho dù bạn chọn kiểu nào, hãy nhất quán để nó không trở thành chi phí cho bộ não của bạn để xử lý nhiều kiểu trong các đoạn mã liên quan . Trong các kịch bản khác nhau (như ở trên) tôi sẽ nói sử dụng các phong cách khác nhau là ổn, việc 'chuyển ngữ cảnh' ở mức cao sẽ dễ dàng hơn.

Bạn không bao giờ nên làm phương pháp thứ 3.

Lướt qua niềng răng lần đầu tiên có thể giúp bạn tiết kiệm một vài lần nhấn phím, nhưng lập trình viên tiếp theo đi kèm, thêm điều gì đó vào mệnh đề khác của bạn mà không nhận thấy khối bị thiếu niềng răng sẽ gây ra rất nhiều đau đớn.

Viết mã của bạn cho người khác.

Trong một thời gian dài, tôi lập luận rằng chúng có giá trị như nhau, hoặc rất gần bằng với mức tăng có thể bằng cách đưa ra lựa chọn đúng là rất xa, thấp hơn nhiều so với chi phí tranh luận về nó.

Sự nhất quán là quan trọng , mặc dù. Vì vậy, tôi đã nói hãy lật một đồng xu và viết mã.

Tôi đã thấy các lập trình viên chống lại sự thay đổi như thế này trước đây. Hãy vượt qua nó! Tôi đã chuyển đổi nhiều lần trong sự nghiệp của mình. Tôi thậm chí sử dụng các kiểu khác nhau trong C # của mình so với PowerShell.

Vài năm trước tôi đã làm việc trong một nhóm (~ 20 nhà phát triển) đã quyết định yêu cầu đầu vào, sau đó đưa ra quyết định và sau đó thực thi điều đó trên tất cả các cơ sở mã. Chúng tôi sẽ có 1 tuần để quyết định.

Rất nhiều tiếng rên rỉ & đảo mắt. Rất nhiều "Tôi thích cách của tôi, bởi vì nó tốt hơn" nhưng không có chất.

Khi chúng tôi đang nghiên cứu những điểm chính xác hơn của câu hỏi, có người đã hỏi làm thế nào để giải quyết vấn đề này theo kiểu giằng co:

void MyFunction(
    int parameterOne,
    int parameterTwo) {
    int localOne,
    int localTwo
}

Lưu ý rằng không rõ ràng ngay lập tức khi danh sách tham số kết thúc và phần thân bắt đầu. So với:

void MyFunction(
    int parameterOne,
    int parameterTwo) 
{
    int localOne,
    int localTwo
}

Chúng tôi đã đọc một số cách mọi người trên khắp thế giới đã giải quyết vấn đề này và tìm thấy mô hình thêm một dòng trống sau cú đúp mở:

void MyFunction(
    int parameterOne,
    int parameterTwo) {

    int localOne,
    int localTwo
}

Nếu bạn sẽ làm cho một phá vỡ thị giác, bạn cũng có thể làm điều đó với một cái nẹp. Sau đó, phá vỡ thị giác của bạn trở nên nhất quán, quá.

Chỉnh sửa : Hai lựa chọn thay thế cho giải pháp 'dòng trống thêm' khi sử dụng K & R:

1 / Ấn định các đối số hàm khác với thân hàm

2 / Đặt đối số đầu tiên trên cùng một dòng với tên hàm và căn chỉnh thêm các đối số trên các dòng mới cho đối số đầu tiên đó

Ví dụ:

1 /

void MyFunction(
        int parameterOne,
        int parameterTwo) {
    int localOne,
    int localTwo
}

2 /

void MyFunction(int parameterOne,
                int parameterTwo) {
    int localOne,
    int localTwo
}

/Biên tập

Tôi vẫn lập luận rằng tính nhất quán là quan trọng hơn các cân nhắc khác, nhưng nếu chúng ta không có tiền lệ được thiết lập , thì bước đi tiếp theo là cách tốt nhất.

Các quy tắc chính là:

1. Thực hiện theo tiêu chuẩn mã hóa hiện có của dự án.
2. Nếu không có tiêu chuẩn mã hóa và bạn đang chỉnh sửa một cơ sở mã hiện có thuộc sở hữu của người khác - hãy nhất quán với phong cách của mã hiện tại, bất kể bạn thích / không thích nó đến mức nào.
3. Nếu bạn đang làm việc trong một dự án trường xanh - thảo luận với các thành viên khác trong nhóm và đi đến thống nhất về một tiêu chuẩn mã hóa chính thức hoặc không chính thức.
4. Nếu bạn đang làm việc trong một dự án lĩnh vực xanh với tư cách là nhà phát triển duy nhất - tạo nên tâm trí của riêng bạn, và sau đó nhất quán một cách tàn nhẫn.

Ngay cả khi bạn không có ràng buộc bên ngoài nào, tốt nhất bạn nên tìm kiếm một hướng dẫn mã hóa hoặc tiêu chuẩn mã hóa hiện có (được sử dụng rộng rãi) và thử làm theo. Nếu bạn cuộn theo phong cách của riêng bạn, có một cơ hội tốt mà bạn sẽ phải hối tiếc trong một vài năm.

Cuối cùng, một kiểu được triển khai / thực hiện bằng cách sử dụng trình kiểm tra kiểu và trình định dạng mã hiện có sẽ tốt hơn một kiểu cần được "thi hành" theo cách thủ công.

Lợi ích của phương pháp đầu tiên là nó nhỏ gọn hơn theo chiều dọc, do đó bạn có thể phù hợp với nhiều mã hơn trên màn hình của mình và đó là lý do tại sao tôi thích nó hơn. Đối số duy nhất tôi nghe thấy có lợi cho phương pháp thứ hai là nó giúp việc ghép ngoặc mở và đóng dễ dàng hơn, nhưng hầu hết các IDE đều có một phím tắt cho điều đó và thực sự là một câu lệnh sai - thay vì ghép một dấu ngoặc mở với một đóng khung bạn có thể ghép một dấu ngoặc đóng với biểu thức "bắt đầu khối" (if, other, for, while) trên cùng một mức thụt đầu dòng, vì vậy thật dễ dàng để xác định vị trí bắt đầu của khối.

Tôi thấy không có lý do gì để lãng phí toàn bộ một dòng chỉ cho một dấu ngoặc khi trước đó cho / while / nếu cấu trúc đã trực quan chỉ ra sự bắt đầu của một khối.

Điều đó nói rằng, tôi tin rằng khung đóng phải nằm trong dòng riêng của nó bởi vì chúng ta cần một cái gì đó để chỉ ra sự kết thúc của một khối và cấu trúc thụt đầu dòng của nó theo một cách có thể nhìn thấy.

tôi thích

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

kết thúc

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

bởi vì dòng you.postAnswer();này dễ đọc và dễ nhìn hơn từ cái nhìn đầu tiên. Theo cách thứ hai, nó được hòa trộn với dòng phía trên nó ( you.hasAnswer()) khiến mắt tôi phải tập trung hơn để đọc nó.

Tôi thích phương pháp đầu tiên. Niềng răng hoàn toàn không có giá trị riêng biệt.

Có điều là niềng răng không quan trọng. Chúng chỉ là rác tổng hợp , điều hoàn toàn không cần thiết để hiểu mã là gì, về mục đích và cách thức triển khai. Chúng chỉ là một sự tôn vinh đối với các ngôn ngữ giống như kiểu C cũ, nơi việc nhóm các nhà khai thác trực quan là không thể do không gian màn hình thấp có sẵn.

Có những ngôn ngữ (Python, Haskell, Ruby) vẫn ổn mà không cần niềng răng. Điều này chỉ xác nhận rằng niềng răng là rác, và không nên xứng đáng có một dòng cho chúng bất cứ khi nào có thể:

if (you.hasAnswer()){
    you.postAnswer();
}else{
    you.doSomething();
}

Sử dụng Python và bỏ qua hoàn toàn đối số.

Vị trí của niềng răng nên

metadata

cấu hình trong IDE bởi lập trình viên. Bằng cách đó, những dấu ngoặc nhọn trong tất cả các mã, bất kể tác giả, trông giống nhau.

Nó phụ thuộc.

Nếu tôi đang mã hóa bằng Javascript hoặc jQuery, tôi sử dụng mẫu đầu tiên:

jQuery(function($) { 
    if ($ instanceOf jQuery) { 
        alert("$ is the jQuery object!"); 
    } 
}); 

Nhưng nếu tôi viết mã bằng C #, tôi sử dụng mẫu thứ hai, vì đó là cách chính tắc để làm điều đó trong C #.

public int CalculateAge(DateTime birthDate, DateTime now) 
{ 
    int age = now.Year - birthDate.Year; 
    if (now.Month < birthDate.Month 
        || (now.Month == birthDate.Month && now.Day < birthDate.Day)) 
        age--; 
    return age; 
} 

Lưu ý rằng ví dụ của bạn có thể được viết

if (you.hasAnswer())
    you.postAnswer();
else
    you.doSomething();

trong C #.

Tôi thích cái đầu tiên vì tôi khó nhìn thấy lỗi hơn trong ví dụ này.

if (value > maximum);
{
    dosomething();
}

hơn trong ví dụ này

if (value > maximum); {
    dosomething();
}

Điều này ; {có vẻ sai đối với tôi hơn là một dòng kết thúc với ;vì vậy tôi có nhiều khả năng nhận thấy nó.

Tôi thích một biến thể nhỏ của 1)

if (you.hasAnswer()) {
    you.postAnswer();
} // note the break here
else {
    you.doSomething();
}

Tại sao?

• Tôi nghĩ rằng luôn luôn đặt niềng răng trên dòng riêng của họ làm giảm khả năng đọc. Tôi chỉ có thể chứa một số mã nguồn nhất định trên màn hình của mình. Kiểu khung 2) làm cho các thuật toán nặng nề với rất nhiều vòng lặp lồng nhau và các điều kiện dài một cách đau đớn.

• Tuy nhiên, tôi muốn elsebắt đầu một dòng mới vì ifvà elsethuộc về nhau, trực quan. Nếu có một dấu ngoặc ở phía trước else, sẽ khó khăn hơn nhiều để phát hiện ra cái gì thuộc về cái gì.

• 3) không đủ tiêu chuẩn. Chúng ta đều biết những điều tồi tệ có thể xảy ra nếu bạn bỏ dấu ngoặc và quên nó đi.

Tôi đã đọc ở đâu đó rằng các tác giả của một số cuốn sách muốn mã của họ được định dạng như thế này:

if (you.hasAnswer())
{
    you.postAnswer();
}
else
{
    you.doSomething();
}

Nhưng các hạn chế về không gian từ nhà xuất bản của họ có nghĩa là họ phải sử dụng điều này:

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Bây giờ tôi không biết liệu điều đó có đúng không (vì tôi không thể tìm thấy nó nữa), nhưng phong cách thứ hai rất phổ biến trong sách.

Ở cấp độ cá nhân, tôi thích các dấu ngoặc trên một dòng riêng biệt như:

a) họ chỉ ra một phạm vi mới
b) dễ dàng phát hiện hơn khi bạn có sự không phù hợp (mặc dù đây không phải là vấn đề trong IDE làm nổi bật các lỗi cho bạn).

Ah, Phong cách cú đúp thực sự .

Nó có mọi thứ cần thiết cho Holy Way - thậm chí là một nhà tiên tri (Richard "cách của tôi hoặc đường cao tốc" Stallman).

Anh chàng đã sai rất nhiều về rất nhiều thứ, nhưng GNU là điểm nổi bật khi nói đến niềng răng.

[Cập nhật] Tôi đã thấy ánh sáng, và bây giờ tôn thờ Allman

Ví dụ thứ hai, tôi rất lớn về khả năng đọc. Tôi không thể đứng nhìn nếu chặn bất kỳ cách nào khác = (

Câu trả lời đơn giản: cái gì dễ gỡ lỗi hơn?

// Case 1:
void dummyFunction() {
  for (i = 0; i != 10; ++i) {
    if (i <= 10)
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there";
  }
} // COMPILER ERROR HERE


// Case 2:
void dummyFunction()
{
  for (i = 0; i != 10; ++i)

    if (i <= 10)
    {
      std::cout << "i is: " << i << "\n";
      std::cout << 10 - i << " steps remaining\n";

      // Some hard work here
      // which is really hard
      // and does take some screen estate
    }
    else
      std::cout << "We'll never get there\n";
  }
} // COMPILER ERROR HERE

Trong trường hợp nào bạn đã chẩn đoán vấn đề đầu tiên?

Tôi không quan tâm nhiều đến sở thích cá nhân (có nhiều phong cách khác, bao gồm cả người da trắng và cộng sự) và tôi không quan tâm nhiều ... miễn là nó không cản trở khả năng đọc mã của tôi và gỡ lỗi của tôi.

Đối với đối số "không gian lãng phí", tôi không mua nó: Tôi có xu hướng thêm các dòng trống giữa các nhóm logic để làm cho chương trình rõ ràng hơn ...

Không phải ai cũng chú ý, nhưng đây là lý do tại sao niềng răng thuộc về cùng một dòng với điều kiện (ngoại trừ các điều kiện rất dài, nhưng đó là trường hợp cạnh):

Trong C, đây là một cấu trúc hợp lệ:

trong khi (đúng);
{
    char c;
    getar (); // Đợi đầu vào
}

Nhanh chóng! Mã này làm gì? Nếu bạn trả lời "vòng lặp vô hạn yêu cầu đầu vào", bạn đã sai! Nó thậm chí không nhận được đầu vào. Nó bị bắt tại while(true). Lưu ý rằng dấu chấm phẩy ở cuối. Mô hình này thực sự phổ biến hơn mà có vẻ như nó phải như vậy; C yêu cầu bạn khai báo các biến của bạn khi bắt đầu một khối, đó là lý do tại sao một biến mới được bắt đầu.

Một dòng mã là một suy nghĩ. Niềng răng là một phần của ý nghĩ chứa điều kiện hoặc vòng lặp. Do đó, chúng thuộc cùng một dòng.

Tôi thích phương pháp đầu tiên. Nó có vẻ gọn gàng hơn IMO, và nó nhỏ gọn hơn, mà tôi thích.

EDIT: Ah, một phần ba. Tôi thích cái đó tốt nhất khi có thể, vì nó thậm chí còn nhỏ hơn / gọn gàng hơn.

Bạn có thể viết nó:

you.hasAnswer() ? you.postAnswer() : you.doSomething();

Để trả lời câu hỏi; Tôi đã từng thích sử dụng dấu ngoặc nhọn trên dòng riêng của họ, nhưng, để tránh phải suy nghĩ về các lỗi từ chèn dấu chấm phẩy tự động trong trình duyệt, tôi bắt đầu sử dụng kiểu Ai Cập cho javascript. Và khi mã hóa java trong nhật thực, tôi không có hứng thú với việc chiến đấu (hoặc cấu hình) kiểu niềng răng mặc định, vì vậy tôi cũng đã đi với Ai Cập trong trường hợp đó. Bây giờ tôi ổn với cả hai.

Gần như tất cả các câu trả lời ở đây đều nói một số biến thể về "Dù bạn làm gì, hãy gắn bó với một hoặc hai".

Vì vậy, tôi nghĩ về nó một lúc và phải thừa nhận rằng tôi không thấy nó quan trọng. Bất cứ ai có thể thành thật nói với tôi rằng những điều sau đây là khó theo dõi?

int foo(int a, Bar b) {
    int c = 0;
    while(a != c)
    {
        if(b.value[a] == c) {
            c = CONST_A;
        }
        c++;
    }
    return c;
}

Tôi không chắc chắn về bất cứ ai khác ... nhưng tôi hoàn toàn không có vấn đề gì về mặt tinh thần chuyển đổi qua lại giữa các phong cách. Tôi đã mất vài phút để tìm ra mã đã làm gì, nhưng đó là kết quả của việc tôi chỉ gõ ngẫu nhiên cú pháp giống như C. :)

Theo ý kiến ​​không hề khiêm tốn của tôi, việc niềng răng mở gần như hoàn toàn không liên quan đến khả năng đọc mã. Có một vài trường hợp góc được liệt kê ở trên trong đó một kiểu này hoặc kiểu kia tạo ra sự khác biệt, nhưng đối với hầu hết các phần, việc sử dụng hợp lý các dòng trống sẽ làm sạch nó.

FWIW, các kiểu mã hóa của chúng tôi tại nơi làm việc sử dụng mẫu 1 có cấu trúc hơn một chút và mẫu 3. được sửa đổi (C ++)

            // blank line is required here
if (x) {
            //This blank line is required
   y = z;
}
            // blank line is required here too, unless this line is only another '}'

if (x) y = z; //allowed

if (x)
    y = z;  // forbidden

Tôi tò mò liệu những người mạnh mẽ thích mẫu 2 sẽ tìm thấy phiên bản của mẫu 1 này tốt hơn, chỉ vì dòng trống mang lại sự tách biệt thị giác mạnh mẽ hơn.

Tôi ngạc nhiên khi điều này chưa được nêu ra. Tôi thích cách tiếp cận thứ hai vì nó cho phép bạn chọn khối dễ dàng hơn.

Khi niềng răng bắt đầu và kết thúc trên cùng một cột và trên dòng riêng của chúng, Bạn có thể chọn từ lề hoặc bằng con trỏ trên cột 0. Điều này thường tương đương với một khu vực hào phóng hơn với lựa chọn chuột hoặc ít lần nhấn phím hơn với lựa chọn bàn phím.

Ban đầu tôi làm việc với niềng răng trên cùng một dòng với điều kiện, nhưng khi tôi chuyển đổi, tôi thấy nó tăng tốc độ mà tôi làm việc. Tất nhiên, đó không phải là ngày và đêm, nhưng điều gì đó sẽ khiến bạn chậm lại khi làm việc với niềng răng bên cạnh điều kiện của bạn.

Cá nhân tôi thích cách thứ hai.

Tuy nhiên, theo cách tôi sẽ chứng minh là theo ý kiến ​​của tôi tốt nhất bởi vì nó mang lại sự bảo mật công việc lớn nhất! Một sinh viên từ trường đại học của tôi đã nhờ tôi giúp đỡ về bài tập về nhà và đây là cách mã của anh ấy trông như thế nào. Toàn bộ chương trình trông giống như một khối duy nhất. Điều thú vị là 95% lỗi trong chương trình mà anh ấy tạo ra đến từ niềng răng không khớp. 5% khác là rõ ràng một khi niềng răng được khớp.

while(1){
i=0;
printf("Enter coded text:\n");
while((s=getchar())!='\n'){
         if(i%1==0){
            start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!");
exit(1);}
input=start;}
      input[i++]=s;}
start=(char*)realloc(input,(i+1)*sizeof(char));
if(start==NULL){
printf("Memory allocation failed!!!");
exit(1);}
input=start;
input[i]='\0';
                puts(input);

Sở thích cá nhân của tôi là phương pháp đầu tiên, có lẽ vì đó là cách đầu tiên tôi học PHP.

Đối với ifbáo cáo một dòng , tôi sẽ sử dụng

if (you.hasAnswer()) you.postAnswer();

Nếu nó không phải you.postAnswer();là một cái gì đó dài hơn nhiều, chẳng hạn như you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);tôi có thể trở lại loại đầu tiên:

if (you.hasAnswer) {
    you.postAnswer(this.AnswerId, this.AnswerText, this.AnswerType);
}

Tôi sẽ không bao giờ sử dụng ngắt dòng và tôi sẽ không bao giờ sử dụng phương pháp này nếu có elsetuyên bố.

if (you.hasAnswer()) you.postAnswer();
else you.doSomething()

là một khả năng lý thuyết, nhưng không phải là một cái tôi từng sử dụng. Điều này sẽ phải được biến thành

if (you.hasAnswer()) {
    you.postAnswer();
} else {
    you.doSomething();
}

Họ không nên; phương pháp đầu tiên cho tôi.

Khi tôi nhìn vào cái thứ hai, vì các dòng không được sử dụng (những dòng chỉ có dấu ngoặc, không phải là dấu ngoặc cuối cùng), nó có cảm giác như nó phá vỡ tính liên tục của mã. Tôi không thể đọc nó nhanh vì tôi cần đặc biệt chú ý đến các dòng trống, điều này thường có nghĩa là sự phân tách trong mục đích mã hoặc một cái gì đó như thế này, nhưng trong trường hợp "dòng này thuộc về một dấu ngoặc nhọn" (chỉ lặp lại ý nghĩa của vết lõm).

Dù sao, giống như khi bạn viết văn bản ... thêm một vết lõm ở đầu đoạn văn là không cần thiết nếu có một dòng trống trước nó (dấu hiệu kép của thay đổi đoạn văn), không cần phải lãng phí dòng cho dấu ngoặc khi chúng ta thụt lề đúng cách.

Thêm vào đó, như đã nêu, nó cho phép điều chỉnh nhiều mã hơn trong màn hình, điều này ngược lại sẽ hơi phản tác dụng.

Nó phụ thuộc vào nền tảng / ngôn ngữ / quy ước

Trong Java:

void someMethod() { 
     if (you.hasAnswer()) {
         you.postAnswer();
     } else {
       you.doSomething();
     }
}

Trong C #

void someMethod() 
{ 
     if (you.hasAnswer()) 
     {
         you.postAnswer();
     } 
     else 
     {
       you.doSomething();
     }
}

Trong C:

void someMethod() 
{ 
     if (you_hasAnswer()) {
         you.postAnswer();
     } else {
       you_doSomething();
     }
}

Tôi ghét khi những người Java sử dụng phong cách của họ trong mã C # và ngược lại.

Tất cả những gì tôi có thể nói là nếu bạn là người hâm mộ phương pháp # 3, bạn sẽ bị bức hại bởi mọi trình định dạng mã IDE trên trái đất.

Tôi sử dụng phương pháp đầu tiên đơn giản vì nó nhỏ gọn hơn và cho phép nhiều mã hơn trên màn hình. Bản thân tôi chưa bao giờ gặp vấn đề với việc ghép đôi niềng răng (tôi luôn viết chúng ra, cùng vớiif câu lệnh trước khi thêm điều kiện và hầu hết các môi trường cho phép bạn nhảy đến phù hợp).

Nếu bạn đã cần ghép lên niềng răng bằng mắt, sau đó tôi sẽ thích phương pháp thứ hai. Tuy nhiên, điều đó cho phép ít mã hơn cùng một lúc đòi hỏi bạn phải cuộn nhiều hơn. Và điều đó, đối với tôi ít nhất, có tác động lớn hơn đến việc đọc mã hơn là có niềng răng được sắp xếp gọn gàng. Tôi ghét di chuyển. Sau đó, một lần nữa, nếu bạn cần cuộn qua một ifcâu lệnh, rất có thể nó quá lớn và cần tái cấu trúc.

Nhưng; điều quan trọng nhất của tất cả là sự nhất quán. Sử dụng cái này hay cái kia - không bao giờ cả hai!

Khi tôi lần đầu tiên học lập trình ở tuổi 12, tôi đã đặt niềng răng ở dòng tiếp theo bởi vì các hướng dẫn mã hóa của Microsoft là như thế. Tôi cũng thụt lề với TABS 4 không gian lúc đó.

Sau một vài năm, tôi đã học Java và JavaScript và thấy nhiều mã niềng răng trên cùng một dòng, vì vậy tôi đã thay đổi. Tôi cũng bắt đầu thụt lề với SPACES 2 không gian.

Có một tùy chọn thứ 4 giữ cho niềng răng thẳng hàng, nhưng không lãng phí không gian:

if (you.hasAnswer())
{    you.postAnswer();
     i.readAnswer();
}
else
{   you.doSomething();
}

Vấn đề duy nhất là hầu hết các bộ lọc tự động của IDE bị nghẹt thở vì điều này.

Tất cả phụ thuộc vào bạn miễn là bạn không làm việc trong một dự án nơi mà một số ràng buộc mã hóa hoặc một số tiêu chuẩn đã được đặt ra bởi người quản lý dự án mà tất cả các lập trình viên đang làm việc trong dự án đó phải tuân theo trong khi mã hóa.

Cá nhân tôi thích phương pháp 1

Ngoài ra tôi không nhận được những gì bạn muốn hiển thị bằng phương pháp thứ 3?

Đó không phải là một cách sai? Ví dụ, hãy xem xét một tình huống như ..

if (you.hasAnswer())
  you.postAnswer();
else
  you.doSomething();

Bây giờ nếu ai đó muốn thêm một số câu lệnh trong if khối?

Trong trường hợp đó nếu bạn sử dụng phương thức thứ 3, trình biên dịch sẽ đưa ra lỗi cú pháp.

if (you.hasAnswer())
   you.postAnswer1();
   you.postAnswer2();
else
   you.doSomething();